Method and structure to develop a test program for semiconductor integrated circuits

ABSTRACT

Test program development for a semiconductor test system, such as automated test equipment (ATE), using object-oriented constructs is described. The invention provides a method for describing test system resources, test system configuration, module configuration, test sequence, test plan, test condition, test pattern, and timing information in general-purpose object-oriented constructs, e.g., C++ objects and classes. In particular, the modularity of program development is suitable for developing test programs for an open architecture semiconductor test system.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of application No.60/447,839, “Method and Structure to Develop a Test Program forSemiconductor Integrated Circuits,” filed Feb. 14, 2003; application No.60/449,622, “Method and Apparatus for Testing Integrated Circuits,”filed Feb. 24, 2003; U.S. application Ser. No. 10/404,002, “Testemulator, test module emulator, and record medium storing programstherein,” filed Mar. 31, 2003; and U.S. application Ser. No. 10/403,817,“Test Apparatus and Test Method,” filed Mar. 31, 2003, all of which areincorporated herein in their entirety by reference. This applicationalso incorporates by reference in its entirety U.S. application no.______, “Method and Apparatus for Testing Integrated Circuits,” filedconcurrently herewith, which claims the benefit of application No.60/449,622, “Method and Apparatus for Testing Integrated Circuits,”filed Feb. 24, 2003.

BACKGROUND OF THE INVENTION

[0002] 1. Field of Invention

[0003] The present invention relates to the testing of integratedcircuits (ICs), and more particularly to developing a test program forautomated semiconductor test equipment (ATE).

[0004] 2. Description of Related Art

[0005] Today tester manufacturers use their own proprietary languages todevelop test programs for semiconductor test systems (testers). Forexample, machines produced by Advantest Corporation utilize the TestDescription Language (TDL), and Credence Systems offers its own WaveformGeneration Language (WGL). To overcome this degree of specialization, ICand tester manufacturers tried to find a common ground by developingIEEE standard 1450, the Standard Test Interface Language (STIL). STIL,however, is a highly specialized language for defining pins, testcommands, timing, etc. Moreover, a test engineer running STILnevertheless still needs to translate STIL into the proprietarymanufacturer-specific language required by the tester. Thus STIL merelyserves as an intermediate language that is nonetheless highlyspecialized and not generally known to programmers.

[0006] Hence, it is desirable to develop a method through which testprogram can be written in a general purpose language. Moreover, thismethod should allow for easy development of test programs for an openarchitecture test system.

SUMMARY OF THE INVENTION

[0007] This application describes test program development usingobject-oriented constructs, e.g., C++ objects and classes. Inparticular, this method is suitable for developing test programs for anopen architecture tester, such as that described in U.S. applicationSer. Nos. 60/449,622, 10/404,002 and 10/403,817, assigned to theassignee of the present invention.

[0008] An embodiment of the present invention provides a method fordeveloping a test program by describing test system resources, testsystem configuration, module configuration, test sequence, test plan,test condition, test pattern and timing information in general-purposeobject-oriented, e.g., C/C++, constructs to test a device under test,e.g., an IC, on a semiconductor test system, such as automated testequipment (ATE). The files containing these descriptions are stored inmemory, i.e., a computer-readable medium, accessible to the test systemor related equipment that uses the files.

[0009] Describing test system resources may comprise specifying aresource type, where the resource type is associated with at least onetest module for applying a test to the IC, specifying a parameter typeassociated with the resource type, and specifying a parameter of theparameter type.

[0010] Describing test system configuration may comprise specifying asite controller for controlling at least one test module, where eachtest module applies a test to the IC, and specifying an input port of amodule connection enabler. The test system couples the site controllerto the module connection enabler at the specified input port, and themodule connection enabler couples the site controller to a test module.The module connection enabler may be implemented as a switch matrix.

[0011] Describing module configuration may comprise specifying a moduleidentifier for specifying a module type, specifying executable code forcontrolling a test module of the module type specified by the moduleidentifer, and specifying a resource type associated with the testmodule. The executable code may take the form of a dynamic link library.

[0012] Describing module configuration may further involve the userspecifying a slot identifier for specifying an output port of the moduleconnection enabler, where the test system couples the test module to themodule connection enabler at the output port, and the module connectionenabler couples the test module to a corresponding site controller. Theuser may also specify a vendor identifier for identifying the providerof the test module, and an identifier of the maximum number of resourceunits available in connection with the resource type. The resource typemay be, for example, digital tester pins and the resource units testerchannels. Alternatively, the tester channel resource units may alsocorrespond to resource types such as, for example, analog tester pins,RF tester pins, power supply pins, digitizer pins, and arbitrarywaveform generation pins. An indicator relating to which resource unitsare disabled may also be provided. The resource units indicated asdisabled may represent defective resource units of the test module.

[0013] Describing test conditions may comprise specifying at least onetest condition group, specifying a specification set including at leastone variable; and specifying a selector for selecting an expression tobe bound to a variable. Association of the test condition group with aselector for the specification set defines a test condition.

[0014] Describing a test sequence may comprise specifying the order (orflow) in which various tests can be applied.

[0015] Describing test patterns may comprise specifying the testpatterns, associated voltage and current levels, transitions in signalvalues, corresponding rise and fall times and associated timing.

[0016] An embodiment of the present invention also includes the use ofpreheader files. A preheader file is compiled to create a header filefor a class associated with a test entity. The preheader includes aparameter block for specifying parameters for setting at least oneattribute of the test entity, and a template block for specifying sourcecode that is inserted by a compiler into the header file for the testentity class. The header file may be a C++ header file. The test entitymay be a test and the test entity class may be a test class, forexample. The parameters may relate to pattern lists and test conditions,for example.

[0017] A pattern compiler of an embodiment of the invention includes atleast one module-specific pattern compiler, and an object file managerfor directing each module-specific compiler to compile both acorresponding module-specific section of a pattern source file and acommon section of the pattern source file. The common section includesinformation accessible to all of the module-specific compilers. Anoutput of the compiler includes at least one module-specific patterndata section. Module-specific pattern loaders load into correspondingtest modules module-specific pattern data from correspondingmodule-specific pattern data sections for execution.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018]FIG. 1 illustrates a conventional tester architecture.

[0019]FIG. 2 illustrates a tester architecture according to anembodiment of the present invention.

[0020]FIG. 3 illustrates a tester software architecture according to anembodiment of the present invention.

[0021]FIG. 4 illustrates a test program compiler according to anembodiment of the present invention.

[0022]FIG. 5 illustrates how different test instances may be derivedfrom a single test class according to an embodiment of the presentinvention.

[0023]FIG. 6 illustrates a pattern compiler according to an embodimentof the present invention.

[0024]FIG. 7 illustrates a ordered pattern tree example according to anembodiment of the present invention.

[0025]FIG. 8 illustrates another ordered pattern tree example accordingto an embodiment of the present invention.

[0026]FIG. 9 illustrates the relationships among files that are requiredby a test program according to an embodiment of the present invention.

[0027]FIG. 10 illustrates waveform generation according to an embodimentof the present invention.

[0028]FIG. 11 illustrates a mapping used for timing according to anembodiment of the present invention.

[0029]FIG. 12 illustrates another mapping used for timing according toan embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] The present invention is generally described in terms of the Openarchitecture test system as disclosed in U.S. application Ser. Nos.60/449,622, 10/404,002 and 10/403,817 by the same assignee. Thoseskilled in the art will recognize, however, that embodiments of the testprogram development system and method of the present invention areapplicable not only to an open tester architecture, but also to fixedtester architectures, as well.

[0031] A description of the open architecture test system may be foundin U.S. application no. ______, “Method and Apparatus for TestingIntegrated Circuits,” filed concurrently herewith, which claims thebenefit of U.S. application No. 60/449,622 by the same assignee.

[0032]FIG. 1 illustrates a generalized architecture of a conventionaltester showing how a signal is generated and applied to adevice-under-test (DUT). Each DUT input pin is connected to a driver 2that applies test data, while each DUT output pin is connected to acomparator 4. In most cases, tri-state driver-comparators are used sothat each tester pin (channel) can act either as an input pin or as anoutput pin. The tester pins dedicated to a single DUT collectively forma test site that works with an associated timing generator 6, waveformgenerator 8, pattern memory 10, timing data memory 12, waveform memorydata 14, and block 16 that define the data rate.

[0033]FIG. 2 illustrates a system architecture 100 according to anembodiment of the present invention. A system controller (SysC) 102 iscoupled to multiple site controllers (SiteCs) 104. The system controllermay also be coupled to a network to access files. Through a moduleconnection enabler 106, each site controller is coupled to control oneor more test modules 108 located at a test site 110. The moduleconnection enabler 106 allows reconfiguration of connected hardwaremodules 108 and also serves as a bus for data transfer (for loadingpattern data, gathering response data, providing control, etc.).Possible hardware implementations include dedicated connections, switchconnections, bus connections, ring connections, and star connections.The module connection enabler 106 may be implemented by a switch matrix,for example. Each test site 110 is associated with a DUT 112, which isconnected to the modules of the corresponding site through a loadboard114. In one embodiment, a single site controller may be connected tomultiple DUT sites.

[0034] The system controller 102 serves as the overall system manager.It coordinates the site controller activities, manages system-levelparallel test strategies, and additionally provides for handler/probecontrols as well as system-level data-logging and error handlingsupport. Depending on the operational setting, the system controller 102can be deployed on a CPU that is separate from the operation of sitecontrollers 104. Alternatively a common CPU may be shared by the systemcontroller 102 and the site controllers 104. Similarly, each sitecontroller 104 can be deployed on its own dedicated CPU (centralprocessing unit), or as a separate process or thread within the sameCPU.

[0035] The system architecture can be conceptually envisioned as thedistributed system shown in FIG. 2 with the understanding that theindividual system components could also be regarded as logicalcomponents of an integrated, monolithic system, and not necessarily asphysical components of a distributed system.

[0036]FIG. 3 illustrates a software architecture 200 according to anembodiment of the present invention. The software architecture 200represents a distributed operating system, having elements for thesystem controller 220, at least one site controller 240, and at leastone module 260 in correspondence to related hardware system elements102, 104, 108. In addition to the module 260, the architecture 200includes a corresponding element for module emulation 280 in software.

[0037] As an exemplary choice, the development environment for thisplatform can be based on Microsoft Windows. The use of this architecturehas side benefits in program and support portability (e.g., a fieldservice engineer could connect a laptop which runs the tester operatingsystem to perform advanced diagnostics). However, for largecompute-intensive operations (such as test pattern compiles), therelevant software can be made as an independent entity capable ofrunning independently to allow job scheduling across distributedplatforms. Related software tools for batch jobs are thus capable ofrunning on multiple platform types.

[0038] As an exemplary choice, ANSI/ISO standard C++ can be taken as thenative language for the software. Of course, there are a multitude ofoptions available (to provide a layer over the nominal C++ interfaces)that allows a third party to integrate into the system with analternative language of its own choice.

[0039]FIG. 3 illustrates a shading of elements according to theirorganization by nominal source (or collective development as asub-system) including the tester operating system, user components 292(e.g., supplied by a user for test purposes), system components 294(e.g., supplied as software infrastructure for basic connectivity andcommunication), module development components 296 (e.g., supplied by amodule developer), and external components 298 (e.g., supplied byexternal sources other than module developers).

[0040] From the perspective of source-based organization, the testeroperating system (TOS) interface 290 include: System Controller to SiteController interfaces 222, framework classes 224, Site Controller toModule interfaces 245, framework classes 246, predetermined module-levelinterfaces, backplane communications library 249, chassis slot IF(Interface) 262, loadboard hardware IF 264, backplane simulation IF 283,loadboard simulation IF 285, DUT simulation IF 287, Verilog PLI(programming language interface) 288 for DUT's Verilog model and C/C++language support 289 for DUT's C/C++ model.

[0041] User components 292 include: a user test plan 242, user testclasses 243, hardware loadboard 265, and DUT 266, a DUT Verilog model293 and a DUT C/C++ model 291.

[0042] System components 294 include: system tools 226, communicationslibrary 230, test classes 244, a backplane driver 250, HW backplane 261,simulation framework 281, backplane emulation 282, and loadboardsimulation 286.

[0043] Module-development components 296 include: module commandsimplementation 248, module hardware 263, and module emulation 284.

[0044] External components 298 include external tools 225.

[0045] The system controller 220 includes interfaces 222 to sitecontroller, framework classes 224, system tools 226, external tools 225,and a communications library 230. The System Controller software is theprimary point of interaction for the user. It provides the gateway tothe Site Controllers of the invention, and synchronization of the SiteControllers in a multi-site/DUT environment as described in U.S.application No. 60/449,622 by the same assignee. User applications andtools, graphical user interface (GUI)-based or otherwise, run on theSystem Controller. The System Controller also may act as the repositoryfor all Test Plan related information, including Test Plans, testpatterns and test parameter files. The memory storing these files may belocal to the system controller or offline, e.g., connected to the systemcontroller through a network. A test parameter file containsparameterization data for a Test class in the object orientedenvironment of an embodiment of the invention.

[0046] Third party developers can provide tools in addition to (or asreplacements for) the standard system tools 226. The standard interfaces222 on the System Controller 220 include interfaces that the tools useto access the tester and test objects. The Tools (applications) 225, 226allow interactive and batch control of the test and tester objects. Thetools include applications for providing automation capabilities(through, for example, the use of SECS/TSEM, etc.)

[0047] The Communications library 230 residing on the system controller220 provides the mechanism to communicate with the Site Controllers 240in a manner that is transparent to user applications and test programs.

[0048] The Interfaces 222 resident in memory associated with the SystemController 220 provide open interfaces to the framework objects thatexecute on the System Controller. Included are interfaces allowing theSite Controller-based module software to access and retrieve patterndata. Also included are interfaces that applications and tools use toaccess the tester and test objects, as well as scripting interfaces,which provide the ability to access and manipulate the tester and testcomponents through a scripting engine. This allows a common mechanismfor interactive, batch and remote applications to perform theirfunctions.

[0049] The Framework Classes 224 associated with the System Controller220 provide a mechanism to interact with these above-mentioned objects,providing a reference implementation of a standard interface. Forexample, the site controller 240 of the invention provides a functionaltest object. The system controller framework classes may provide acorresponding functional test proxy as a remote system controller-basedsurrogate of the functional test object. The standard functional testinterface is thus made available to the tools on the system controller220. The framework classes effectively provide an operating systemassociated with the host system controller. They also constitute thesoftware elements that provide the gateway to the Site Controllers, andprovide synchronization of the Site Controllers in a multi-site/DUTenvironment. This layer thus provides an object model in an embodimentof the invention that is suitable for manipulating and accessing SiteControllers without needing to deal directly with the Communicationslayer.

[0050] The site controller 240 hosts a user test plan 242, user testclasses 243, standard test classes 244, standard interfaces 245, sitecontroller framework classes 246, module high level command interfaces(i.e., predetermined module-level interfaces 247, module commandsimplementation 248, backplane communications library 249, and abackplane driver 250. Preferably most of the testing functionality ishandled by the site controllers 104/240, thus allowing independentoperation of the test sites 110.

[0051] A Test Plan 242 is written by the user. The plan may be writtendirectly in a standard computer language employing object-orientedconstructs, such as C++, or described in a higher level test programminglanguage to produce C++ code, which can then be compiled into theexecutable test program. For test program development, one embodiment ofthe invention employs assignee's inventive Test Program Language (TPL)compiler. Referring to FIG. 4, the test program compiler 400 acts inpart as a code generator including a translator section 402 to translatea test program developer's source files 404 describing tests andassociated parameters into object-oriented constructs, such as C++ code.A compiler section 406, in turn, compiles and links the code intoexecutables, e.g., DLLs, to create the test program that may be executedby the tester system. Although the application of the TPL codegenerator/translator to test systems is novel, please note that codegenerators are known in the art. Also, the compiler section may be astandard C++ compiler known in the art.

[0052] The test plan creates test objects by using the Framework Classes246 and/or standard or user supplied Test Classes 244 associated withthe site controllers, configures the hardware using the StandardInterfaces 245, and defines the test plan flow. It also provides anyadditional logic required during execution of the test plan. The testplan supports some basic services and provides an interface to theservices of underlying objects, such as debug services (e.g.,break-pointing), and access to underlying framework and standardclasses.

[0053] The source code input to the test program compiler 400 includes aTest Plan description file that specifies the objects used in a testplan and their relationships to one another. This file is translated toC++ code that is executed on the Site Controller in the form of animplementation of a standard interface, which may be denoted ITestPlan.This code is packaged into a Windows dynamic link library (DLL), whichmay be loaded onto the Site Controller. The Test Program DLL isgenerated to have standard known entry points that the Site Controllersoftware can use to generate and return the TestPlan object it contains.The Site Controller software loads the Test Program DLL into its processspace and uses one of the entry points to create an instance of the TestPlan object. Once the Test Plan object has been created, the SiteController software can then execute the test plan.

[0054] The Framework classes 246 associated with the site controllersare a set of classes and methods that implement common test-relatedoperations. The site controller-level framework includes, for example,classes for power supply and pin electronics sequencing, setting leveland timing conditions, obtaining measurements, and controlling testflow. The framework also provides methods for runtime services anddebugging. The framework objects may work through implementing thestandard interfaces. For example, the implementation of the TesterPinframework class is standardized to implement a general tester pininterface that test classes may use to interact with hardware modulepins.

[0055] Certain framework objects may be implemented to work with thehelp of the module-level interfaces 247 to communicate with the modules.The site controller framework classes effectively act as a localoperating system supporting each site controller.

[0056] In general more than ninety percent of the program code is datafor the device test, and the remaining ten percent of the code realizesthe test methodology. The device test data is DUT-dependent (e.g., powersupply conditions, signal voltage conditions, timing conditions, etc.).The test code consists of methods to load the specified deviceconditions on to ATE hardware, and also those needed to realizeuser-specified objectives (such as datalogging). The framework of anembodiment of the invention provide a hardware-independent test andtester object model that allows the user to perform the task of DUT testprogramming.

[0057] To increase the reusability of test code, such code may be madeindependent of any device-specific data (e.g., pin name, stimulus data,etc.), or device-test-specific data (e.g., conditions for DC units,measurement pins, number of target pins, name of pattern file, addressesof pattern programs). If code for a test is compiled with data of thesetypes, the reusability of the test code would decrease. Therefore,according to an embodiment of the invention, any device-specific data ordevice-test-specific data may be made available to the test codeexternally, as inputs during code execution time.

[0058] In an embodiment of the invention, a Test Class, which is animplementation of a standard test interface, denoted here as ITest,realizes the separation of test data and code (and hence, thereusability of code) for a particular type of test. Such a test classmay be regarded as a “template” for separate instances of itself, whichdiffer from each other only on the basis of device-specific and/ordevice-test-specific data. Test classes are specified in the test planfile. Each Test class typically implements a specific type of devicetest or setup for device test. For example, an embodiment of theinvention may provide a specific implementation of the ITest interface,for example, FunctionalTest, as the base class for all functional testsfor DUTs. It provides the basic functionality of setting testconditions, executing patterns, and determining the status of the testbased on the presence of failed strobes. Other types of implementationsmay include AC and DC test classes, denoted here as ACPararnetricTestsand DCParametricTests.

[0059] All test types may provide default implementations of somevirtual methods (e.g., init( ), preExec( ), and postexec( )). Thesemethods become the test engineer's entry points for overriding defaultbehavior and setting any test-specific parameters. However, custom testclasses can also be used in test plans.

[0060] Test classes allow the user to configure class behavior byproviding parameters that are used to specify the options for aparticular instance of that test. For example, a Functional Test maytake parameters PList and TestConditionS, to specify the Pattern List toexecute, and the Level and Timing conditions for the test, respectively.Specifying different values for these parameters (through the use ofdifferent “Test” blocks in a test plan description file) allows the userto create different instances of a Functional Test. FIG. 5 illustrateshow different test instances may be derived from a single test class.These classes may be programmed directly in object-oriented constructs,such as C++ code, or designed to allow a test program compiler to takethe description of the tests and their parameters from a test plan fileand generate corresponding C++ code, which can be compiled and linked togenerate the test program. A Template Library may be employed as thegeneral-purpose library of generic algorithms and data structures. Thislibrary may be visible to a user of the tester, so that the user may,for example, modify the implementation of a test class to create auser-defined test class.

[0061] As to user-developed test classes, an embodiment of the systemsupports integration of such test classes into the framework in that alltest classes derive from a single test interface, e.g., ITest, so thatthe framework can manipulate them in the same way as the standard set ofsystem test classes. Users are free to incorporate additionalfunctionality into their test classes, with the understanding that theyhave to use custom code in their test programs to take advantage ofthese additional facilities.

[0062] Each test site 110 is dedicated to testing one or more DUTs 106,and functions through a configurable collection of test modules 112.Each test module 112 is an entity that performs a particular test task.For example, a test module 112 could be a DUT power supply, a pin card,an analog card, etc. This modular approach provides a high degree offlexibility and configurability.

[0063] The Module Commands Implementation classes 248 may be provided bymodule hardware vendors, and implement either the module-levelinterfaces for hardware modules, or provide module-specificimplementations of standard interfaces, depending on the commandsimplementation method chosen by a vendor. The external interfaces ofthese classes are defined by pre-determined module level interfacerequirements, and backplane communications library requirements. Thislayer also provides for extension of the standard set of test commands,allowing the addition of methods (functions) and data elements.

[0064] The Backplane Communications Library 249 provides the interfacefor standard communications across the backplane, thereby providing thefunctions necessary to communicate with the modules connected to thetest site. This allows vendor-specific module software to use aBackplane Driver 250 to communicate with the corresponding hardwaremodules. The backplane communications protocol may use a packet basedformat.

[0065] Tester Pin objects represent physical tester channels and derivefrom a tester pin interface, denoted here as ITesterPin. The softwaredevelopment kit (SDK) of an embodiment of the invention provides adefault implementation of ITesterPin, which may be called TesterPin,which is implemented in terms of a predetermined module-level interface,IChannel. Vendors are free to make use of TesterPin if they canimplement their module's functionality in terms of IChannel; otherwise,they must provide an implementation of ITesterPin to work with theirmodule.

[0066] The standard module interface, denoted here as IModule, providedby the tester system of the invention generically represents a vendor'shardware module. Vendor-supplied module-specific software for the systemmay be provided in the form of executables such as dynamic linklibraries (DLLs). Software for each module-type from a vendor may beencapsulated in a single DLL. Each such software module is responsiblefor providing vendor-specific implementations for the module interfacecommands, which comprise the API for module software development.

[0067] There are two aspects of the module interface commands: first,they serve as the interface for users to communicate (indirectly) with aparticular hardware module in the system, and second, they provide theinterfaces that third-party developers can take advantage of tointegrate their own modules into the site controller level framework.Thus, the module interface commands provided by the framework aredivided into two types:

[0068] The first, and most obvious, are those “commands” exposed to theuser through the framework interfaces. Thus, a tester pin interface(ITesterPin) provides methods to get and set level and timing values,while a power supply interface (IPowerSupply) provides methods forpowering up and powering down, for example.

[0069] In addition, the framework provides the special category of thepredetermined module-level interfaces, which can be used to communicatewith the modules. These are the interfaces used by framework classes(i.e., “standard” implementations of framework interfaces) tocommunicate with vendor modules.

[0070] However, the use of the second aspect, the module-levelinterfaces, is optional. The advantage of doing so is that vendors maythen take advantage of the implementations of classes such as ITesterPinand IPowerSupply, etc. while focusing on the content of specificmessages sent to their hardware by implementing the module-levelinterfaces. If these interfaces are inappropriate to the vendor,however, they may choose to provide their custom implementations of theframework interfaces (e.g., vendor implementations of ITesterPin,IPowerSupply, etc.). These would then provide the custom functionalitythat is appropriate for their hardware.

[0071] With this open architecture as background, the test programdevelopment system of the present invention is further described asfollows. Section A below describes rules to describe the testenvironment in which test program will be used; section B describes themethod and rules for test program development; section C specifies themethod and rules to develop a test plan and how to define the mainstructure of the test program; section D describes how to run a testprogram on an open architecture test system; section E describes amethod and rules for test patterns; section F describes rules todescribe the timing of the test patterns; and section G describes rulesfor the overall tester operation.

[0072] A. Components

[0073] The test environment comprises a set of files that specify thenecessary conditions for bringing up the tester, and for preparing it torun a set of tests. The test environment preferably includes files for:

[0074] 1. Tester Resource definition: for the specification of the typesof tester resources—and supported parameters for such resources—that areavailable in the open architecture test system.

[0075] 2. Tester configuration: for the specification of SiteControllers, sites and corresponding mappings.

[0076] 3. Module configuration: for specification of the hardware modulein each site

[0077] 4. Pin descriptions: for naming of DUT pins, such as signal pins,power supplies, and to describe pin groups,

[0078] 5. Socket: for the specification of DUT pin-to-tester pinassignments

[0079] 6. Pin options: for the specification of special options, ormodes, for pins.

[0080] 7. Pattern lists: for the specification of test patterns andtheir sequence.

[0081] 8. Patterns: for the specification of test vectors.

[0082] Of the above, items 1-3 are created by ICF (installation andconfiguration files) with information from a CMD (configurationmanagement database), and made available at a well-known location, whileitems 4-8 are user-specified. This section provides descriptions for theitems 1-6 above; items 7-8 are described in more detail in section E.Specific methods and rules are preferably used to develop each of thesecomponents; these methods and rules will be described in this sectionwith examples.

[0083] A1. The Resource Definition

[0084] Each hardware module provides one or more types of hardwareresources (resources for short) for use by the test system. The testerResource Definition is preferably used to declare a set of resourcenames for the available resource types, and a set of parameter names andtypes associated with each particular resource type. For instance, theresource name dpin is used to refer to digital tester pins. Theseresources have parameters such as VIL (for the input low voltage), VIH(for the input high voltage), VOL (for the output low voltage), VOH (forthe output high voltage), etc. A resource definition file will have theextension “.rsc”. Shown below is an example resource definition,containing some tester resources: # # File Resources.rsc # Version0.1.2; ResourceDefs { # digital pins dpin { # Low and High voltages forinput pins Voltage VIL, VIH; # Low and High voltages for output pinsVoltage VOL, VOH; } # power supplies dps { # # PRE_WAIT specifies thetime to wait after voltage # reached its final value to start pattern #generation. The actual time that the system # will wait is a smallsystem specified range: # PRE_WAIT−delta <= actual <= PRE_WAIT+delta # #PRE_WAIT_MIN is a minimum amount to wait after voltage # reached itsfinal value to start pattern generation. # It is a system specifiedrange: # PRE_WAIT_MIN <= actual <= PRE_WAIT_MIN+delta # # POST_WAITspecifies the time to wait after pattern # generation ends to shut downthe power. The actual # time that the system will wait is a small system# defined range: # POST_WAIT−delta <= actual <= POST_WAIT+delta # #POST_WAIT_MIN specifies the time to wait after pattern # generation endsto shut down the power. The actual # time that the system will wait is asmall system # defined range: # POST_WAIT_MIN <= actual <=POST_WAIT_MIN+delta # Time PRE_WAIT; Time PRE_WAIT_MIN; Time POST_WAIT;Time POST_WAIT_MIN; # The voltage. Voltage VCC; } }

[0085] Note that the type of a resource parameter (such as Voltage orTime) is preferably a standard engineering unit. Vendors supplyingspecial purpose resources that prefer the specification of differentparameters should provide their own resource definition files.

[0086] Structure for the Resource Definition

[0087] Given below is a structure for the resource definition file inaccordance with a preferred embodiment of the present invention:resource-file: version-info resource-defs version-info: Versionversion-identifer ; resource-defs: ResourceDefs { resource-def-list }resource-def-list: resource-def resource-def-list resource-defresource-def: resource-name { resource-params-decl-list }resource-params-decl-list: resource-params-declresource-params-decl-list resource-params-decl resource-params-decl:elementary-type-name resource-param-name-list ;resource-param-name-list: resource-param-name resource-param-name-list ,resource-param-name

[0088] Undefined non-terminals above are specified below:

[0089] 1. version-identifier: A sequence of one or more characters fromthe set [0-9a-zA-Z.]. It represents a version number.

[0090] 2. resource-name: A sequence of one or more characters from theset [a-zA-Z_(—)0-9], not starting with a digit. It represents the nameof a resource, such as dpin or dps.

[0091] 3. elementary-type-name: A sequence of one or more charactersfrom the set [a-zA-Z_(—)0-9], not starting with a digit. It representsthe name of an elementary type, such as Voltage (cf.).

[0092] 4. resource-param-name: A sequence of one or more characters fromthe set [a-zA-Z_(—)0-9], not starting with a digit. It represents thename of a resource parameter, such as VIL.

[0093] A2. Tester Configuration

[0094] The The Tester Configuration is a set of rules that is preferablyused to list the Site Controllers in a particular system configuration,and the connection of the Site Controllers to the Switch Matrix inputports. In the architecture of an embodiment of the invention, a singleSite Controller can be connected to a single switch matrix input port.Thus, in this context, the switch matrix connections serve as implicitidentifiers for the Site Controllers in the system (other configurationsare possible). The following is an example of a typical testerconfiguration: # # Tester Configuration, Sys.cfg # Version 1.2.5;SysConfig { # # The first field is the hostname of the Site Controllermachine; # it can be specified as either a dotted-decimal IP address ora # domain-qualified hostname. # # The second field is the switch matrixinput port number, which # implicitly serves as the identifier for theSite Controller # connected to it. # zeus.olympus.deities.org 2;127.0.0.2 4; 127.0.0.0 1; # SITEC-1 127.0.0.3 3; }

[0095] The system configuration for a particular test-floor system ispart of the system profile, and is made available as the systemconfiguration file Sys.cfg. Note that in one embodiment the SiteController connected to port 1 (“127.0.0.0” in the above example) mayenjoy special status, in which it alone configures the Switch Matrix.This “special” Site Controller will be referred to as SITEC-1. Also notethat the site controller address in this example is an IP addressbecause the site controllers may be connected to the system controllerby an internal network. Conversely, the system controller may beconnected to an external network to access files, such as pattern data.

[0096] Structure for the Tester Configuration

[0097] Given below is a structure for the system configuration file inaccordance with an embodiment of the present invention:system-config-file: version-info system-config version-info: Versionversion-identifer ; system-config: SysConfig {site-controller-connection-list } site-controller-connection-list:site-controller-connection site-controller-connection-listsite-controller-connection site-controller-connection:site-controller-hostname input-port ; site-controller-hostname:ip-address domain-qualified-hostname ip-address: octet . octet . octet .octet domain-qualified-hostname: name domain-qualified-hostname . name

[0098] Undefined non-terminals above are specified below:

[0099] 1. version-identifier: A sequence of one or more characters fromthe set [0-9a-zA-Z.]. It represents a version number.

[0100] 2. octet: A nonnegative integer from 0 to 255 (in decimalnotation).

[0101] 3. name: A sequence of one or more characters from the set[a-zA-Z_(—)0-9], not starting with a digit. It represents a name segmentin a domain-qualified hostname.

[0102] 4. input-port: A nonnegative integer, in decimal notation.

[0103] A3. The Module Configuration

[0104] The Module Configuration allows the specification of the physicalconfiguration of the tester, e.g., the physical location and type ofeach module in a SYSTEM chassis. This is necessitated by the dynamicnature of the tester bus configuration, which allows a mapping of thetester bus address to the physical slot location. This informationallows a hardware discovery process that occurs at system boot-up timeto validate the SYSTEM configuration. Each output port of the SwitchMatrix defines a physical slot, which is preferably occupied by a singlehardware module. Shown below is an example of a module configurationspecified in the file Modules.cfg in accordance with an embodiment ofthe invention: # # Module Configuration File, Modules.cfg # Version0.0.1; ModuleConfig { # # A configuration definition which providesinformation about # the module type that is attached to slots 1-12 and32-48. # Note that a module might provide more than # a single type ofresource. # Slot 1-12, 32-48 # Switch matrix output ports # which usethe configuration # defined below. { VendorID 1; # defined vendor code.ModuleID 1; # Vendor-defined id code. ModuleDriver mod1.dll; # Modulesoftware. # # Resource named dpin specifies channels # for digital data.The name dpin is not # a keyword. It is simply the name of a hardware #resource, and is obtained from the resource # definition file. #Resource dpin { MaxAvailable32; # Resource units 1 .. 32. } Resourceanalog { MaxAvailable16; # Resource units 1 .. 16. Disabled 1-8; #Disabled resources 1 .. 8. # So, enabled ones are 9 .. 16. } } # # Aconfiguration definition which provides information about # the moduletype that is attached to slots 16-30, 50, and 61-64. # Slot 16-30, 50,61-64 { Resource dpin { MaxAvailable32; # Max available resource units.Disabled 3, 30-32; # Disabled resources. } ModuleDriver “moduletwo.dll”; VendorID 2; ModuleID 2; } # # A configuration definition,which provides information about # the module type that is attached toslots 65-66. # Slot 65-66 { ModuleID 4; # DPS module with 8 supplies.ModuleDriver mod4.dll; VendorID 1; # # Resource type dps specifyingresource units for a # Device Power Supply # Resource dps {MaxAvailable4; Disabled 1; } } }

[0105] As mentioned earlier, in one embodiment a slot refers toconnector through which a hardware module can be connected, such as anoutput port of the switch matrix. Each configuration definition providesinformation about the module that may be attached to one or more slots.The VendorID specified in a configuration definition is a unique IDassociated with a vendor. The ModuleID refers to a type of moduleprovided by this vendor. There may be several instances of the sameModuleID in a tester configuration. The ModuleDriver refers to a vendorsupplied DLL to service the module. Finally, the Resource refers to theunits serviced by this module, and provides a name for the resourcetype; the resource name is obtained from the resource definition file.

[0106] The above example describes three configuration blocks in amodule configuration file. In one implementation, the firstconfiguration block, slots 1-12 and 32-48 are serviced by a moduleproduced by vendor 1. This vendor provides the module, the identifier“1” to refer to this module type, and the module driver library tocontrol the module. This module can provide two types of resource units,one designated by the resource name “dpin”, with preferably a totalnumber of 32 resource units (i.e., “channels”), all of which areavailable, and the other designated by the resource name “analog”, witha total number of 16 resource units, of which only 9 through 16 areavailable. The second and third configuration blocks are specified in amanner similar to the first configuration.

[0107] Note that the provision for allowing channels to be denoted as“disabled” is to allow for the identification of defective resourceunits on modules that are still functional otherwise. Note also that aconfiguration block may have one or more slot identifiers. When a blockhas more than a single slot identifier, then the identified slots aresaid to be cloned.

[0108] The module configuration file, Modules.cfg, is created as part ofthe system profile by the ICM (installation configuration managementsystem) (with test-floor-specific information provided by the user), andmade available at a well-known location. The ICM is a utility that canbe local to the test system, e.g., on the system controller, or resideelsewhere on the network to which the system controller is connected.The ICM manages the CMD (configuration management database), andtypically updated on hardware changes to the system configuration. ICMallows the user to configure the system, e.g., site controllers andmodules. The CMD is a database that stores the configurations. Foractual tester configuration/operation ICM generates the configurationfiles, e.g., module configuration, and other files, and copies them andassociated files, such as particular module DLLs, onto the tester.

[0109] Structure for Module Configuration

[0110] Below is the module configuration structure in accordance withthe preferred embodiment: file-contents: version-info module-config-defversion-info: Version version-identifier ; module-config-def:ModuleConfig { slot-entry-list } slot-entry-list: slot-entryslot-entry-list slot-entry slot-entry: Slot positive-integer-list {slot-info } slot-info: required-config-list required-config-list:required-config required-config-list required-config required-config:VendorID id-code ; ModuleID id-code ; ModuleDriver file-name ; Resourceresource-name { max-spec disabled-spec_(opt) } max-spec: MaxAvailablepositive-integer ; disabled-spec: Disabled positive-integer-list ;positive-integer-list: positive-integer-list-entrypositive-integer-list, positive-integer-list-entrypositive-integer-list-entry: positive-integerpositive-integer-number-range positive-integer-number-range:positive-integer - pos-integer

[0111] Undefined non-terminals above are described below:

[0112] 1. version-identifier: A sequence of one or more characters fromthe set [0-9a-zA-Z.], where the first character must be from the set[0-9].

[0113] 2. positive-integer: A sequence of one or more characters fromthe set [0-9], not starting with a 0.

[0114] 3. id-code: A sequence of one or more characters from the set[a-zA-Z_(—)0-9].

[0115] 4. resource-name: A sequence of one or more characters from theset [a-zA-Z_(—)0-9], where the first character must be from the set[a-zA-Z].

[0116] Comments are supported; comments start with the ‘#’ character,and extend to the end of the line.

[0117] A4. Pin Descriptions

[0118] The DUT pin descriptions are described using a Pin Descriptionsfile. The user makes available a description of the DUT pins in a pindescription file, which has the extension pin. This plain text filecontains, at least the following: a listing of the DUT pin names; andinitial definitions of named pin groups, which make use of the definedDUT pin names (“initial” since they can be subsequently modified oradded to, etc., programmatically).

[0119] The separation of this data specification from the Test Plandescription allows general reuse of the DUT pin definitions, and allowsthe pattern compiler to derive pin names (required for resolvingreferences to pin names used in vector specifications) from the pindescription file, without having the process tied to a specific TestPlan.

[0120] Shown below is an example pin description file: # # Pindescription file, myDUT.pin. # # Note that this implicitly imports theresource # configuration file,Resources.rsc. # Version 1.1.3a;PinDescription { Resource dpin { A0; A1; A2; A3; A4; # This syntaxexpands to the names “ABUS[1]” and “ABUS[2]” ABUS[1:2]; A5; BBUS[1:8];DIR; CLK; Group Grp1 { DIR, CLK, A0, A1, A2, A3, A4, BBUS[1:4] } GroupGrp2 { A5, # # The following line will expand to #“DIR, A1, A2, A4, A5,BBUS[2] ”: # Grp1 − CLK − A0 − A3 − BBUS[1] − BBUS[3:4] + A5, BBUS[5:8]} } Resource dps { vcc1; vcc2; vcc3; Group PSG { vcc1, vcc2 } } }

[0121] resource type blocks, to allow the compiler to correlate pin andpin group definitions with the allowable parameter settings for Levels,etc.

[0122] The following points about pin descriptions should be noted:

[0123] 1. Pin groups and pins share the same namespace and have global(i.e., Test Plan) scope. One of the consequences of the global scopingof these names is that pins and pin groups cannot use duplicated names,even when declared in different resource blocks.

[0124] 2. At least one Resource definition is required in the pindescription file.

[0125] 3. At least one pin name should be defined in each resource.

[0126] 4. Pin and group names are required to be unique within resourceboundaries.

[0127] 5. The same pin or group name can be defined for two or moreresources. However, duplicates within the same resource are ignored.

[0128] 6. All pin names and group names that appear in a groupdefinition should have been already defined within that resource.

[0129] 7. Group definitions, if given, should have at least one pin nameor group name (i.e., a group definition cannot be empty).

[0130] 8. A pin group definition can include a reference to apreviously-defined pin group.

[0131] 9. A pin group definition can include set operations such asaddition and subtraction of previously defined pins and/or pin groups.

[0132] Structure for the Pin Descriptions

[0133] Given below is the structure for the pin descriptions inaccordance with the preferred embodiment of the present invention:pin-description-file: version-info pin-description version-info: Versionversion-identifer ; pin-description: PinDescription {resource-pins-def-list } resource-pins-def-list: resource-pins-defresource-pins-def-list resource-pins-def resource-pins-def: Resourceresource-name { pin-or-pin-group-def-list } pin-or-pin-group-def-list:pin-or-pin-group-def pin-or-pin-group-def-list pin-or-pin-group-defpindef-or-pin-groupdef: pin-def ; pin-group-def pin-def: pin-namepin-name [ index : index ] pin-group-def: Group pin-group-name {pin-group-def-item-list } pin-group-def-item-list: pin-defpin-group-def-item-list, pin-def

[0134] Undefined non-terminals above are specified below:

[0135] 1. version-identifier: A sequence of one or more characters fromthe set [0-9a-zA-Z.]. It represents a version number.

[0136] 2. resource-name: A sequence of one or more characters from theset [a-zA-Z_(—)0-9] not starting with a digit. It represents the name ofa resource, such as dpin or dps.

[0137] 3. pin-name: A sequence of one or more characters from the set[a-zA-Z_(—)0-9] not starting with a digit. It represents the name of apin A0.

[0138] 4. pin-group-name: A sequence of one or more characters from theset [a-zA-Z_(—)0-9] not starting with a digit. It represents the name ofa pin group ABUS.

[0139] 5. index: A nonnegative integer. It represents the lower bound oran upper bound on a group of related pins.

[0140] A5. The Socket

[0141] The Socket specifies the mapping between DUT pin names andphysical tester pin (channel) assignments (the physical tester channelnumbers are defined in the module configuration file). Note thatdifferent Sockets can be used to support different DUT packages anddifferent load board configurations, etc. For a multi-DUT system, theSocket definitions for DUT/channel assignments can support “cloning” ofa basic Socket to multiple sites. However, different Sockets (i.e.,different physical mappings for the same logical pins) should respectsite module partitions. Thus, in addition to providing DUT pin to testerchannel assignments, the socket also effectively defines the sitepartitioning. A Socket file could thus contain definitions for severalindividual site sockets. Shown below is a sample socket file definingthree DUT sites: Version 1.1.3 SocketDef { DUTType Pentium3 {PinDescription dutP3.pin; # The pin description file for Pentium3 DUT 2# Uses the full-specification syntax { SiteController 1; # Switch Matrixinput port Resource dpin { # # The CLK pin is assigned to resource dpin,# slot 2, resource unit (channel) 13. # CLK 2.13; # # The DIR pin isassigned to resource dpin, # slot 5, resource unit 15. DIR 5.15; # # Thefollowing statement will be expanded to # BBUS[7] 5.4 # BBUS[6] 5.5 #BBUS[5] 5.6 # # So for example, the pin sequence BBUS[7], BBUS[6], #BBUS[5] is assigned to the same slot 5, and to # resource units 4, 5 and6 respectively. # BBUS[7:5] 5.[4:6]; BBUS[1:4] 7.[21:18]; BBUS[8] 9.16;} Resource dps { # # The V1 pin is assigned to resource dps, # slot 1,resource unit (channel) 1. # VCC1 1.1; # # The VCC2 pin is assigned toresource dps, # slot 1, resource unit (channel) 2. # VCC2 1.2; } } # EndDUT 2 DUT 1 # This is “cloned” from DUT 2 above { SiteController 1; #Same Site Controller as for DUT 2 Resource dpin { SlotOffset 1; # Offsetvalue for slots } Resource dps { SlotOffset 10; # Offset value for slots} # # The offset syntax above indicates that the slot/resource # unitassignments are “cloned” from the first DUT defined # for this DUTType,i.e., DUT 2, with the slots offset by # the SlotOffset values. # #Looking at the definition of dpin resource units for # DUT 2, CLK isbound to slot 2. Hence, for the present # DUT, CLK is bound to slot 2 +1 = 3. # # Some of the new bindings in effect due to the offset #assignments are shown in the table below: # #--------------------------------------------------- # Pin Resource RUnitSlot # --------------------------------------------------- # CLK dpin 132 + 1 = 3 # DIR dpin 15 5 + 1 = 6 # BBUS[8] dpin 16 9 + 1 = 10 # VCC1dps 1 1 + 10 = 11 # VCC2 dps 2 1 + 10 = 11 # } # End DUT 1 } # EndDUTType Pentium3 DUTType 74LS245 { PinDescription dutLS.pin; DUT 3disabled # This DUT site is disabled, and will be ignored { ... } } #End DUTType 74LS245 } # End SocketDef

[0142] The following points about a Socket file should be noted:

[0143] 1. The Socket file uses information from both moduleconfiguration file, and the user's pin description files for the givenDUT types (see specification for PinDescription in the example above).The module configuration information is made implicitly available to theSocket file compiler. The socket file compiler is a subpart of thepattern compiler that reads and analyzes the socket DUT name to testerchannel mapping, and the module configuration and pin description filesto set up the mapping of tester pins to DUT pins used by the patterncompiler.

[0144] 2. At least one DUT site definition per DUT type is required, andit must use the full-specification syntax, as opposed to the SlotOffsetsyntax. If more than one DUT site definition is provided for the sameDUT type, the first one must use the full-specification syntax.

[0145] 3. Each subsequent DUT site definition (for the same DUT type)may use either the full-specification syntax or the SlotOffset syntax,but not both. This allows individual sites to deviate from a standardpattern (due to, for example, inoperative channels).

[0146] 4. The bindings derived from the SlotOffset syntax are definedrelative to the first site defined for that DUT type (which uses thefull-specification syntax).

[0147] 5. DUT sites do not need to be declared in the actual physicalorder. This allows a case where the first (physical) site deviates fromthe pattern.

[0148] 6. The DUT site IDs are required to be unique across the entireSocket (i.e., across all DUT types defined therein).

[0149] 7. At least one resource definition is required per DUT sitedefinition.

[0150] 8. The site definitions must be used in conjunction with themodule configuration to determine if the test configuration issingle-site/single-DUT or single-site/multi-DUT.

[0151] 9. In all cases, the Socket file should specify a set of DUTchannel mappings which are consistent with the pin description file andthe module configuration file.

[0152] 10. In some cases, it will be desirable to allow the Socketdefinition to specify that one or more DUT channels are disconnectedfrom the tester (for example, by designating the assigned physicalchannel as one with the special ID “0.0”). In this case, these DUTchannels may be used and referenced in the context of the test program.Operations on such channels will result in system warnings (but noterrors.). At load time, pattern data for disconnected channels will bediscarded.

[0153] Structure for the Socket

[0154] Below is the structure for the module configuration in accordancewith a preferred embodiment of the present invention: socket-file:version-info socket-def version-info: Version version-identifer ;socket-def: SocketDef { device-specific-socket-def-list }device-specific-socket-def-list: device-specific-socket-defdevice-specific-socket-def-list device-specific-socket-defdevice-specific-socket-def: DUTType DUT-type-name { pin-description-filedut-info-list } pin-description-file: PinDesc pin-description-file-name; dut-info-list: dut-info dut-info-list dut-info dut-info: DUT dut-id {site-controller-input-port resource-info-list }site-controller-input-port: SiteControllerswitch-matrix-input-port-number ; resource-info-list: resource-inforesource-info-list resource-info resource-info: Resource resource-name {resource-item-unit-assignment-list } resource-item-unit-assignment-list:resource-item-unit-assignment resource-item-unit-assignment-listresource-item-unit-assignment resource-item-unit-assignment:resource-item-name slot-number . resource-unit ; resource-item-name [resource-item-index ] slot-number . resource-unit-index ;resource-item-name [ resource-item-index-range ] \ slot-number . [resource-unit-index-range ] ; resource-item-index-range:resource-item-index : resource-item-index resource-unit-index-range:resource-unit-index : resource-unit-index

[0155] Undefined non-terminals above are specified below:

[0156] 1. version-identifier: A sequence of one or more characters fromthe set [0-9a-zA-Z.]. It represents a version number.

[0157] 2. DUT-type-name: A sequence of one or more characters from theset [0-9a-zA-Z.], where the first character must not be from the set[0-9]. It represents a type of DUT, such as Pentium3.

[0158] 3. pin-description-file-name: The simple name of a file, notincluding its directory name, but including all extensions. The filenameis of the syntax recognized by the host operating system, and allowsblanks and other characters if enclosed in quotes.

[0159] 4. switch-matrix-input-port-number: A nonnegative integer indecimal notation to represent the port number of the input portconnected to the Site Controller.

[0160] 5. dut-id: A nonnegative integer in decimal notation to identifyan instance of a DUT.

[0161] 6. resource-name: A sequence of one or more characters from theset [0-9a-zA-Z.], where the first character must not be a digit. Itrepresents the name of a resource defined in a resource file.

[0162] 7. resource-item-name: A sequence of one or more characters fromthe set [0-9a-zA-Z.], where the first character must not be a digit. Itrepresents the name of a resource unit, such as a pin or a pin group.

[0163] 8. resource-item-index: A nonnegative integer in decimal notationthat represents a particular member of a group of resource items. Whenin the context of a resource-item-index-range it represents the lower orupper bound of a contiguous sequence of resource item group.

[0164] 9. resource-unit-index: A nonnegative integer in decimal notationthat represents a particular member of a group of resource units(channels). When in the context of a resource-unit-index-range itrepresents the lower or upper bound of a contiguous sequence of resourceunit group.

[0165] A6. Pins

[0166] Note that in addition to logical pin name to physical channelmappings (as provided by the Socket), several attributes can be used forspecifying the tester resources. For example, options might be used todefine particular hardware configurations for channels, which may betest-specific, vendor-specific, and/or test system-specific. These willbe described using the Pin Mode Options, and made available via a PinMode Options file.

[0167] A Pin Mode Option definition would support the configuration ofspecial options or modes for a tester channel. This could, for example,be used to select and configure channel multiplexing. It is preferredthat the Pin Mode Option only be used as part of a Test Planinitialization flow, since it might require significant channelconfiguration. The Pin Option syntax supports vendor-defined options. Anexample is shown below: PinModeOptions { clock IN double; a0 OUT single;... };

[0168] Test Environment Configuration

[0169] As pointed out earlier, the resource definition file(Resources.rsc), the system configuration file (Sys.cfg) and the moduleconfiguration file (Modules.cfg) are preferably made available at a“well-known” location. This “well-known” location is the directoryspecified by the value of the system environment variableTester_ACTIVE_CONFIGS. For example, if the value ofTester_ACTIVE_CONFIGS is the directory F:\Tester_SYS\configs, the systemwill expect the following files to be present:

[0170] F:\Tester_SYS\configs\Resources.rsc

[0171] F:\Tester_SYS\configs\Sys.cfg

[0172] F:\Tester_SYS\configs\Modules.cfg

[0173] During installation, the Installation and ConfigurationManagement system (ICM) residing on the host computer will preferablyset the value of Tester_ACTIVE_CONFIGS. Every time the ICM creates a newversion of one of the above files, it will place the new version in thelocation pointed to by Tester_ACTIVE_CONFIGS. Note that in addition tothe above three files, other system configuration files such as thesimulation configuration file are also placed in the location pointed toby Tester_ACTIVE_CONFIGS

[0174] B. Rules for Test Program Development

[0175] One of the two principal end-user oriented components of thetester system is the test environment. The other component is theprogramming facility that the tester makes available for the end user(i.e., test engineer and test class developers).

[0176] The principal component of the programming environment is thetest plan. The test plan uses test classes (which are differentimplementations of a test interface denoted Test), which realize theseparation of test data and code for particular types of tests.

[0177] The plan may be written directly as a C++ test program, ordescribed in a test plan description file, which is processed by a TestProgram Generator (translator 402) to produce object-oriented code, suchas C++ code. The generated C++ code can then be compiled into theexecutable test program. The data required for populating a test classinstance, such as levels, timings, etc., are specified by the user inthe test plan description file.

[0178] A test program contains a set of user written files that specifydetails for running a test on a device. An embodiment of the inventionincludes sets of rules that permit a user to write these files using C++constructs.

[0179] One of the requirements according to the embodiment of theinvention is to follow the modularity of the open architecture testsystem. A modular development permits users to write individualcomponents dealing with different aspects of the test, and then permitsthese components to be mixed and matched in various ways to yield acomplete test program. A test program in accordance with the preferredembodiment of the present invention comprises a set of files as follows:

[0180] files *.usrv for user variables and constants;

[0181] files *.spec for specification sets;

[0182] files *.lvl for levels;

[0183] files *.tim for timings;

[0184] files *.tcg for test condition groups;

[0185] files *.bdefs for bin definitions;

[0186] files *.ph for a pre-header, files for custom functions and testclasses.

[0187] files *.ctyp for custom types;

[0188] files *.cvar for custom variables; and

[0189] files *.tpl for test plans.

[0190] The file extensions above are a recommended conventionfacilitating categorization of files. A single test program willpreferably comprise a single test plan file, and the files it imports.An “import” refers to other files with data that is either directlyreferenced by the importer (the file that specifies the import), or isimported by some other file directly referenced by the importer. Thetest plan file could define globals, flows, and other such objectswithin it, or it could import this information from other files. Theserules allows any of the above components to be either in their ownindividual files, or directly inlined into a test plan file. Note thatthe test plan is similar in concept to a C-language main( ) function.

[0191] Test Program Features

[0192] User Variables and Constants,

[0193] Specification Set,

[0194] Levels,

[0195] Timings,

[0196] Test Conditions

[0197] Bin Definition

[0198] Pre-Headers

[0199] Custom Types

[0200] Custom Variables

[0201] Test Plan

[0202] Test program identifiers preferably start with an upper or lowercase alphabetical character, and can subsequently have any number ofalphabetical, numerical, or underscore (_) characters. It has severalkeywords which are provided in the description given below. Thesekeywords are visually identified in code in this document using a boldfont, such as Version. Keywords are reserved, and preferably not be usedas identifiers. There are several special symbols such as {, }, (, ), :,and others which are described below.

[0203] Elaboration of Test Objects

[0204] An import of a test description file enables the importing fileto refer to names of objects made available by the imported file. Thisallows the importing file to reference the objects named by the importedfile. Consider a socket file aaa.soc that imports a pin description filexxx.pin. There could be another bbb.soc file that also imports xxx.pin.However, neither of these imports cause the objects described by xxx.pinto come into existence. They merely reference objects that are alreadyassumed to exist.

[0205] The question arises: when do such objects come into existence?This is where the Test Plan file is fundamentally different. In ananalogy to C, it would be a file with a main( ) routine in it. An“Import” statement in test plan file will elaborate these objects, thatis, cause these objects to come into existence. The test plan mickey.tplshown below causes the objects in xxx.pin and aaa.soc to be elaborated:# File for Mickey's TestPlan Version 3.4.5; # # These import statementswill actually cause the # objects to come into existence: # Importxxx.pin; # Elaborates pin and pin-group objects Import aaa.soc; #Elaborates site socket map objects # Other imports as necessary ... FlowFlow 1 { ... }

[0206] An import of xxx.pin in the test plan causes all the pin and pingroup objects declared in xxx.pin to be elaborated. This is described asfollows: “the file xxx.pin is elaborated”. It is not necessary for aTest Plan to directly import all the files that need to be elaborated. Afile x is imported by a file y if either of the two statements below istrue:

[0207] 1. y has an import statement that names x; or

[0208] 2. x is imported by z, and y has an import statement naming z.

[0209] When a test program is compiled, it will elaborate all theobjects in the files that are imported by the test plan. The set offiles imported by a test plan are topologically sorted to yield an orderin which the files are elaborated. The set of files imported by a testplan is referred to as the import closure of the test plan. If theimport closure of a test plan cannot be topologically sorted, then theremust be an imports cycle. Such a situation is erroneous, and will berejected by the compiler.

[0210] User Variables and Constants

[0211] Global variables and constants will be defined using the UserVariables and Constants. Constants are objects whose value is bound atcompile time, and cannot be changed. The maximum integer value, forinstance, would be a constant. On the other hand, the expression boundto variables can change at runtime via an API.

[0212] Integer,

[0213] UnsignedInteger,

[0214] Double,

[0215] String,

[0216] Voltage in Volts (V),

[0217] VoltageSlew in Volts per Second (VPS),

[0218] Current in Amps (A),

[0219] Power in Watts (W),

[0220] Time in Seconds (S),

[0221] Length in Meters (M),

[0222] Frequency in Hertz (Hz),

[0223] Resistance in Ohms (Ohms), and

[0224] Capacitance in Farads (F).

[0225] The types Integer, UnsignedInteger, Double, and String arereferred to as Basic Types. The Basic Types have no measurement units.The Elementary Types which are not basic types are a Double, with anassociated measurement unit and a scale. The scaling symbols are commonengineering scaling symbols:

[0226] p (pico) for 10−12, as in pF (pico-farad)

[0227] n (nano) for 10−9, as in nS (nano-second)

[0228] u (micro) for 10−6, as in uS (micro-second)

[0229] m (milli) for 10−3, as in mV (milli-amp)

[0230] k (kilo) for 10+3, as in kOhm (kilo-ohm)

[0231] M (mega) for 10+6, as in MHz (mega-hertz)

[0232] G (giga) for 10+9, as in GHz (giga-hertz)

[0233] A separate file with user variables and constants will have theextension .usrv. Below is an example of a file with some globalconstants. An example of a file with some variables is given later. #-------------------------------------------------------- # Filelimits.usrv # --------------------------------------------------------Version 1.0.0; # # This UserVars collection declaration declares a setof # globally available variables and constants. # UserVars { # Someconstant Integer globals used in various places. Const IntegerMaxInteger = 2147483647; Const Integer MinInteger = −2147483648; #Smallest value such that 1.0 + Epsilon != 1.0 Const Double Epsilon =2.2204460492503131e−016; # Some important constants related to DoubleConst Double MaxDouble = 1.7976931348623158e+308; Const Double MinDouble= − MaxDouble; Const Double ZeroPlus = 2.2250738585072014e−308; ConstDouble ZeroMinus = − ZeroPlus; }

[0234] The set of UserVars declared above are considered definitions ofthe variable on the left of the ‘=’. As a result, a single occurrence ofthe definition of a variable or constant is preferred, and it should beinitialized.

[0235] As mentioned earlier, constants should not be changed once theyare defined. The expression bound to a constant can involve previouslydefined constants and literal values. Variables, on the other hand, canbe changed via an API. The expression bound to a variable can involvepreviously defined variables, constants and literal values.

[0236] Each variable is bound to an expression object which ismaintained at runtime. This provides the capability of changing theexpression associated with a variable at runtime, and then re-evaluatingall the variables. The expression object is a parsed form of the righthand side of a variable or constant definition. In one embodiment, nofacility is provided for the changing of constants at runtime. Theirvalue is preferably fixed at compile time.

[0237] Any number of such files with globals can exist in the importclosure of a test plan. While the above globals file is a set of numericlimits, here is a set of engineering globals using engineeringmeasurement units, and some random user variables: #----------------------------------------------- # File myvars.usrv #----------------------------------------------- Version 0.1; # # Thisdeclares a UserVars collection of some engineering # globals. # UserVarsMyVars { # Engineering quantities. Const Voltage VInLow = 0.0; # 0 VoltsConst Voltage VInHigh = 5.0; # 5 Volts Const Voltage VOutLow = 400.0 mV;# 400 milliVolts Const Voltage VOutHigh = 5.1; # 5.1 Volts Const TimeDeltaT = 2.0E−9; # 2 nanoseconds Const Time ClkTick = 1.0ns; # 1nanosecond Const Resistance R10 = 10.0 kOhms; # 10 kilo Ohms # Somevariables are declared below. Current ILow = 1.0 mA; # 1 milliAmpCurrent IHigh = 2.0 mA; # 2 milliAmp Power PLow = ILow * VInLow; # Lowpower value Power PHigh = IHigh * VInHigh; # High power value # # Anarray of low values for all A bus pins. # The vil for A0 will be inABusVil[0], for A1 # in ABusVil[1], and so on. # Voltage ABusVil[8] ={1.0, 1.2, Others = 1.5}; }

[0238] The compiler preferably checks that units and types match up.Note that since a Voltage times a Current yields a Power, the equationsfor PLow and PHigh above will compile. However, a statement such as thefollowing will typically not compile: # # Does not compile because aCurrent and a Voltage cannot be added # to yield a Power. # Power Pxxx =IHigh + VInHigh;

[0239] The compiler will allow certain automatic type conversions: PowerPxxx = 2; # Set the power to 2.0 watts Integer Y = 3.6; # Y getsassigned 3 Power Pyyy = Y; # Pyyy gets assigned 3.0 watts Doubl Z =Pyyy; # Pyyy gets converted to a unitless Double

[0240] Explict type conversion to Double, UnsignedInteger and Integer isalso permitted: Power Pxxx = 3.5; # Explicit type conversion is allowed,but not required # X becomes 3.5 Double X = Double(Pxxx); # X becomes3.5 Integer Y = Integer(Pxxx); # Y becomes 3

[0241] Conversion between unrelated types is also possible, byconverting to an intermediate basic type: Power Pxxx = 3.5; # Explicittype conversion is required. Length L = Double(Pxxx); # L becomes 3.5meters Voltage V = Integer(Pxxx); # V becomes 3.0 Volts.

[0242] The TestPlan object provides a UserVars class which is acollection that contains names and their associated expressions, values,and types. User variables can go into a Default User VariablesCollection, or into a Named User Variables Collection. The UserVarsdeclarations in the example above, which have no specified name, go intothe default collection. However, it is possible to explicitly name acollection as follows: # Declare X and Y in the MyVars UserVarscollection. UserVars MyVars { Integer X = 2.0; # # Refers to the aboveX, and to the globally # available MaxInteger from the default #UserVars collection. # Integer Y = MaxInteger − X; } # Declare X, Y1 andY2 in the YourVars UserVars collection. UserVars YourVars { Integer X =3.0; # Refers to the X from MyVars. Integer Y1 = MaxInteger − MyVars.X;# Refers to the X declared above. Integer Y2 = MaxInteger − X; } # Morevariables being added to the MyVars collection UserVars MyVars { # #Refers to X and Y from the earlier declaration # of MyVars. # Integer Z= X + Y; }

[0243] Name resolution within a UserVars collection proceeds as follows:

[0244] If a name is qualified—i.e., a name comprises two segmentsseparated by a dot—then the variable comes from a named user variablescollection, named by the segment that precedes the dot. So, MyVars.Xabove refers to the X in the MyVars collection. The name “_UserVars” canbe used to explicitly denote the default user variables collection.

[0245] If the name is not qualified, and there is a constant or variableof the same name in the present collection, then the name resolves tothat constant or variable.

[0246] Otherwise, the name resolves to a constant or variable in thedefault user variables collection.

[0247] Evaluation of a block of definitions in a UserVars collection canbe thought of happening sequentially, from the first definition to thelast. This may require each variable being defined before it is used.

[0248] Furthermore, there could be several blocks of definitions for aUserVars collection, each of which are defining several variables. Allof these blocks of definitions can be thought of as being evaluated indeclaration order in the test plan, and then the variables of each blockare also checked in declaration order.

[0249] Finally, there could be several UserVars collections, each ofwhich define variables over several blocks of definitions. All of thevariables again can be thought of as being initialized in declarationorder. Thus, in the above example, the evaluation order would be:MyVars.X, MyVars.Y, YourVars.X, YourVars.Y1, YourVars.Y2, MyVars.Z.

[0250] When a UserVars collection uses a variable from anothercollection, it preferably uses just the raw value of the variable. Nodependency information is maintained between collections. Thus,dependency based re-evaluation can be limited to a single collection.

[0251] Each user variables collection refers to an instance of a C++UserVars class. The default object of the C++ UserVars class is named“_UserVars”. Variables in an UserVars declaration that is unnamed arefrom the default user variables collection, and are added to thisdefault object. Variables in a named user variables collection are addedto an object of the C++ UserVars class having that name. In the aboveexample, the “MyVars” C++ object will end up having the variables X, Yand Z.

[0252] C++ for User Variables

[0253] User variables are implemented as a collection of n-tuples havingthe name string, a const/var boolean, the type as an enumerated valueand the expression as an expression tree. The expression of a name canbe set by a call: enum ElemenaryType {UnsignedIntegerT, IntegerT,DoubleT, VoltageT, ...}; Status setExpression(const String& name, constbool isConst, const elementaryType, const Expression& expression);

[0254] The type Expression is a type that is a parsed form of the textcorresponding to the right hand side of an assignment. There will be aglobally available instance of UserVars. For example, the set of uservariables in limits.usrv (cf. page) is implemented by the set of callsshown below: _UserVars.setExpression(“MaxInteger”, true, IntegerT,Expression(2147483647)); _UserVars.setExpression(“MinInteger”, true,IntegerT, Expression(−2147483648)); _UserVars.setExpression(“Epsilon”,true, DoubleT, Expression(2.2204460492503131e−016));_UserVars.setExpression(“MaxDouble”, true, DoubleT,Expression(1.7976931348623158e+308));_UserVars.setExpression(“MinDouble”, true, DoubleT, Expression(“−MaxDouble”)); _UserVars.setExpression(“ZeroPlus”, true, DoubleT,Expression(2.2250738585072014e−308));_UserVars.setExpression(“ZeroMinus”, true, DoubleT, Expression(“−ZeroPlus”));

[0255] Below are the C++ statements that would be executed for thevariables declared in myvars.usrv: myVars.setExpression(“VInLow”, true,VoltageT, Expression(0.0)); myVars.setExpression(“VInHigh”, true,VoltageT, Expression(5.0)); myVars.setExpression(“DeltaT”, true, TimeT,Expression(2.0E−9)); myVars.setExpression(“ClkTick”, true, TimeT,Expression(1.0E−9)); myVars.setExpression(“R10”, true, ResistanceT,Expression(10.0E+3)); myVars.setExpression(“ILow”, false, CurrentT,Expression(1.0E−3)); myVars.setExpression(“IHigh”, false, CurrentT,Expression(2.0E−3)); myVars.setExpression(“PLow”, false, PowerT,Expression(“ILow * VInLow”)); myVars.setExpression(“PHigh”, false,PowerT, Expression(“IHigh * VInHigh”));myVars.setExpression(“ABusVil[0]”, false, VoltageT, Expression(1.0));myVars.setExpression(“ABusVil[1]”, false, VoltageT, Expression(1.2));myVars.setExpression(“ABusVil[2]”, false, VoltageT, Expression(1.5));myVars.setExpression(“ABusVil[3]”, false, VoltageT, Expression(1.5));myVars.setExpression(“ABusVil[4]”, false, VoltageT, Expression(1.5));myVars.setExpression(“ABusVil[5]”, false, VoltageT, Expression(1.5));myVars.setExpression(“ABusVil[6]”, false, VoltageT, Expression(1.5));myVars.setExpression(“ABusVil[7]”, false, VoltageT, Expression(1.5));

[0256] In the code above, the Expression class preferably hasconstructors that represent the parsed form of the expression.Expression has several constructors, including one that takes a stringliteral and parses it, and another that takes a string literal to usejust as a string literal. These are distinguished by additionalparameters which are not specified above for the sake of readability.

[0257] User variables in the default user variables collection will bemanaged by the _UserVars object of class UserVars. User variables in anamed user variables collection Xxx will be managed by a UserVars objectnamed Xxx.

[0258] Runtime API for UserVars

[0259] The C++ UserVars class that contains these names and expressionsexports an application programming interface (API) to evaluate andmodify these values at runtime. Modification of the expressionsassociated with UserVars also addresses the issue of when the UserVarswill be reevaluated, and what the impact of the evaluation will be.

[0260] Consider first the issue of when the re-evaluation of UserVars asa result of a change should be triggered. If it is triggered immediatelyupon making a change to the expression, then the user would not be ableto make a series of related changes prior to triggering thereevaluation. Consequently, re-evalutation is triggered by an explicitcall by the user.

[0261] The impact of reevaluation can be considered next. There arethree kinds of re-evaluation that are available in accordance with thepreferred embodiment:

[0262] UserVars Collection Re-evaluation is reevaluation limited to asingle UserVars collection. The semantics of this operation is tore-evaluate all the variables of this collection once again.

[0263] UserVars Targeted Re-evaluation is reevaluation limited to achange to the expression bound to a single name. This would enable theuser to change the expression of a single name, and cause there-evaluation of the collection to take place, taking into considerationonly this particular change.

[0264] User Vars Global Re-evaluation is re-evaluation of all UserVarscollections. This basically triggers a re-evaluation of all the UserVarscollections in declaration order and is quite costly.

[0265] All of the above re-evaluations will re-evaluate dependentobjects such as Levels, Timings, etc. after reevaluating the UserVars.Dependent objects will have a dirty bit that represents that it needsre-evaluation. Any time a UserVars collection is programmaticallychanged, it will also set the dirty bit on all dependent objects. Thiswill trigger re-evaluation of the dependent objects.

[0266] In summary, named UserVars collections help contain there-evaluation impact problem. Re-evaluation is normally limited to asingle collection. A simple way of using UserVars would be to only usethe default UserVars collection. That way, the ripple effect of making achange can happen to all UserVars. This ripple effect can be limited byhaving several named UserVars collections.

[0267] Multiple collections can refer to variables from one another, butthe values bound to the variables are bound at time of use. Nodependency is maintained between UserVars collections.

[0268] For each elementary type Xxx (UnsignedInteger, Current, Voltage,etc.), a method to get the value:

[0269] Status getXxxValue(const String& name, Xxx& value) const;

[0270] Note that there is no method to directly set a value, it is donethrough the call to set the expression, followed by a call toreevaluateCollection( ).

[0271] Methods to get and set the expression. The setExpression( ) callcan also be used to define a new variable which was not hithertodefined. enum elementaryType { UnsignedIntegerT, IntegerT, DoubleT,VoltageT, ... }; Status getExpression(const String& name, Expression&expression) const; Status setExpression(const String& name, const boolisConst, const elementaryType, const Expression& expression);

[0272] The setExpression( ) call can fail if the expression results in acircular dependency. For instance if the following two calls were made,the second call would fail with a circular dependency failure

[0273] setExpression(“X”, true, IntegerT, Expression(“Y+1”));

[0274] setExpression(“Y”, true, IntegerT, Expression(“X+1”));

[0275] This is because the values bound to names are equations and arenot assignments. When the value of a variable is changed, a method isprovided to reevaluate all the directly and indirectly dependent names.Equations such as the above pair result in a circular dependency whichis not permitted.

[0276] Note that this API does not typically support unsolicitedre-evaluation. A call to setExpression( ) may not automatically causethe variable, and all other variables that depend on it, to bere-evaluated. The values bound to all variables will stay unchangeduntil a call to reevaluateCollection( ) (below) occurs.

[0277] A method to determine if a particular name is a constant:

[0278] Status getIsConst(const String& name, bool& isConst);

[0279] A method to get the type: enum ElementaryType { UnsignedIntegerT,IntegerT, DoubleT, VoltageT, ... }; Status getType(const String& name,ElementaryType& elementaryType) const;

[0280] The UserVars Collection Re-evaluation method.

[0281] Status reevaluateCollection( );

[0282] The class will maintain equations related to all the variables,and their dependencies. When this method is called, all of the variableswill get re-evaluated.

[0283] The UserVars Targeted Re-evaluation method.

[0284] Status reevaluateTargeted(const String& var);

[0285] The class will maintain equations related to all the variables,and their dependencies. When this method is called, the named variable,and all of its dependents will get re-evaluated.

[0286] The UserVars Global Re-Evaluation Method.

[0287] static Status reevaluateAllCollections( );

[0288] The class will maintain equations related to all the variables,and their dependencies. When this method is called,reevaluateCollection( ) is called on all UserVars collections in anunspecified order.

[0289] A method to determine if a particular name is defined:

[0290] Status getIsDefined(const String& name, bool& isDefined)const;

[0291] A method to determine all the user variables currently defined:

[0292] Status getNames(StringList& names)const;

[0293] A method to delete a presently defined variable:

[0294] Status deleteName(const String& name);

[0295] This operation will fail if the name is used in expressionsinvolving other variables.

[0296] A method to get the list of variables and constants that dependon a given variable or constant:

[0297] Status getDependents(const String& name, StringList& dependents);

[0298] Specification Sets

[0299] The Specification Set is used to supply a collection of variableswhich can take on values based on a Selector. For example, consider thefollowing Specification Set that uses selectors Minnie, Mickey, Goofyand Daisy: # --------------------------------------------------------- #File Aaa.spec #--------------------------------------------------------- Version 1.0;Import Limits.usrv; SpecificationSet Aaa(Minnie, Mickey, Goofy, Daisy) {Double xxx = 1.0, 2.0, 3.0, 4.0; Integer yyy = 10, 20, 30, 40; Integerzzz = MaxInteger − xxx, MaxInteger − xxx − 1, MaxInteger − xxx − 2,MaxInteger − xxx; # The following declaration associates a single #value, which will be chosen regardless of the # selector. It isequivalent to: # Integer www = yyy + zzz, yyy + zzz, yyy + zzz, yyy +zzz Integer www = yyy + zzz; }

[0300] The above Specification Set with the selector Goofy will make thefollowing associations:

[0301] xxx=3.0;

[0302] yyy=30;

[0303] zzz=MaxInteger−xxx−2;

[0304] www=yyy+zzz;

[0305] The operation of setting the selector on a specification set willbe discussed later, when Tests are described.

[0306] Syntactically, a specification set a is list of selectors(Minnie, Mickey, Goofy and Daisy in the example above), along with alist of variable definitions (xxx, yyy, zzz and www in the exampleabove). The definition of a variable involves a list of expressions thatis either as long as the list of selectors, or comprises a singleexpression.

[0307] Conceptually a specification set can be thought of as a matrix ofexpressions, whose columns are the Selectors, whose rows are thevariables and whose entries are expressions. A particular selector(column) binds each variable (row) to a specific expression (entry). Ifthe list has a single expression, it represents a row with theexpression replicated as many times as there are selectors.

[0308] Specification sets can appear in two separate contexts. Theycould be separately declared in a .spec file, in which case they appearas shown above. These are named specification sets. Otherwise, localspecification sets can be declared within a Test Condition Group. Insuch a declaration, the specification set will not be provided with aname. It will be a local specification set, of significance only to theenclosing test condition group.

[0309] Named specification sets can be modeled after the named uservariables collection. The above specification set can be modeled as aUserVars collection named Aaa, which will have expressions forxxx[Minnie], xxx[Mickey], xxx[Goofy], xxx[Daisy], yyy[Minnie], and soon. When a particular selector (say Mickey) is chosen in the context ofa test, the values of xxx, yyy and zzz are obtained from the variablename and the specification set name.

[0310] A test condition group can have at most one specification set,which is either a local specification set, or a reference to a namedspecification set. Local specification sets appear only in the contextof a test condition group, and have no explicitly specified name. Such aspecification set has an implicit name that is defined by the name ofthe enclosing test condition group. To resolve a name in a testcondition group at a point where several specification sets and severalUserVars collections are visible, the following rules are applied:

[0311] 1. If the name is qualified, it must be resolved in a named uservariables collection.

[0312] 2. If the name is not qualified, the name is resolved in either alocal specification set, if it is declared in the test condition group,or in the named specification set, if one is referenced in the testcondition group.

[0313] 3. If the name is not resolved by the earlier rules, it isresolved in the default user variables collection.

[0314] To illustrate these rules, consider the following example usingTest Conditions Groups (to be described later) Version 1.2.3; Importlimits.usrv; # Picks up the limits UserVars file above. Import aaa.spec;# Picks up the Specification Set AAA above. TestConditionGroup TCG1 {SpecificationSet(Min, Max, Typ) { vcc = 4.9, 5.1, 5.0; } # Rule 1:Resolution in a named user variables collection. # A reference toMyVars.VInLow refers to VInLow from MyVars. # Rule 2: Resolution in alocal specification set. # A reference to “vcc” here will resolve in thecontext # of the local specification set above. # Rule 3: Resolution indefault user variables collection. # A reference to “MaxInteger” herewill resolve to limits.usrv. # Error: Resolution of xxx # A reference toxxx does not resolve because it is neither in # the local specificationset, nor in limits.usrv. # Error: Resolution of Aaa.xxx # Looks for anamed UserVars collection named Aaa. The named # specification set doesnot qualify. } TestConditionGroup TCG2 { SpecificationSet Aaa; #References the imported specification set # Rule 1: Resolution in anamed user variables collection. # A reference to MyVars.VInLow refersto VInLow from MyVars. # Rule 2: Resolution in a named specificationset. # A reference to “xxx” here will resolve in the context # of thelocal specification set Aaa above. # Rule 3: Resolution in default uservariables collection. # A reference to “MaxInteger” here will resolve tolimits.usrv. # Error: Resolution of vcc # A reference to vcc does notresolve because it is neither in # the named specification set Aaa, norin limits.usrv. # Error: Resolution of Aaa.xxx # Looks for a namedUserVars collection named Aaa. The named # specification set does notqualify. }

[0315] Resolution of a name in a specification set (rule above) requiresthat a selector of the set be enabled at the time the name resolution isrequired. This will be enforced by the fact that the test conditiongroup will be referenced in a Test by specifying a selector.

[0316] C++ for Specification Sets

[0317] Using the above rules, Specification sets can be implemented bythe C++ SpecificationSet class. The SpecificationSet class hasessentially the same API as the UserVars class, except for an extraString parameter for the selector. Consequently, this API is notdescribed in detail.

[0318] All named specification sets are preferably associated with a C++object of that name. A local specification set in the context of a testcondition group will have a name that is unique to that test conditiongroup. It is illegal to refer to a variable of a local specification setoutside the context of the test condition group that it is defined in.

[0319] Levels

[0320] The Levels are used to specify parameters of pins and pin groups.It is a collection of declarations of the form: <pin-or-pin-group-name>{ <pin-param-1> = xxx; <pin-param-2> = yyy; ... }

[0321] Such a declaration specifies the setting of the variousparameters of the named pin or pin-group. For example, such a statementcould be used to set the VIL values for all pins in the InputPins group,as shown in the example below: #--------------------------------------------------------- # Filepentiumlevels.1vl #--------------------------------------------------------- Version 1.0;Import pentium3resources.rsc; Import pentium3pins.pin; LevelsPentium3Levels { # # Specifies pin-parameters for various pins and # pingroups using globals and values from # the specification set. # # Theorder of specification is significant. # Pin parameters will be set inorder from # first to last in this Levels section, and # from first tolast for each pin or pin-group # subsection. # # From the imported pindescription file pentium3pins.pin, # the InPins group is in the “dpin”resource. From the # imported resource definition filepentium3resources.rsc, # the “dps” resource has parameters named VIL andVIH. # InPins { VIL = v_il; VIH = v_ih + 1.0; } # The followingstatement requires a delay of 10 uS after # the call to set the InPinslevels. Actual delay will be # a small system defined range around10.0E−6. # 10.0E−6 − delta <= actual <= 10.0E−6 + delta Delay 10.0E−6; ## For the OutPins, the levels for the parameters # VOL and VOH arespecified. # OutPins { VOL = v_ol / 2.0; VOH = v_oh; } # The clock pinwill have special values. Clock { VOL = 0.0; VOH = v_ih / 2.0; } # ADelay of 10 uS after the call to set Clock levels. # This is a minimumdelay, that is guaranteed to be for # at least 10.0 uS, though it may bea little more: # 10.0E−6 <= actual <= 10.0E−6 + delta MinDelay 10.0 uS;# # The PowerPins group is in the “dps” resource. Pins of this # pingroup have special parameters: # PRE_WAIT specifies the time to waitafter voltage # reached its final value to start pattern # generation.Actual wait time will be a small # system defined range around PRE_WAIT(see) # POST_WAIT specifies the time to wait after pattern # generationends to shut down the power. Actual # wait time will be a small systemdefined range # around PRE_WAIT (see). # PowerPins { PRE_WAIT = 10.0 ms;POST_WAIT = 10.0 ms; # VCC reaches its final value of 2.0 V from its #present value in a ramp with a Voltage Slew Rate # of ±.01 Volts perSecond. VCC = Slew(0.01, 2.0 V); } } Levels Pentium4Levels { # ... }

[0322] As seen above, each Levels block is preferably made up of anumber of levels items, each of which specifies parameters for a pin orpin group. Each levels item can specify a number of resource parameters.The runtime semantics for the setting of these levels values is asfollows:

[0323] The levels items of the Levels block are processed in declarationorder. Any pin that occurs in more than one levels item will getprocessed multiple numbers of times. Multiple specification of valuesfor a single parameter should be maintained and applied in specificationorder.

[0324] The resource parameters in a levels item are processed in theorder they are specified.

[0325] The Delay statements cause the process of setting levels to pausefor approximately the indicated duration, prior to setting the nextgroup of levels. The actual wait time may be in a small system definedrange around the specified delay. So if the delay was t seconds, theactual delay would satisfy:

[0326] t−Δt<=actual-wait<=t+Δt

[0327] The Delay statements divide up the Levels specification into anumber of subsequences, each of which will require separate TestCondition Memory settings for processing.

[0328] The MinDelay statements cause the process of setting levels topause for at least the specified duration prior to setting the nextgroup of levels. The actual wait time may be in a small system definedrange with a minimum value of the specified minimum delay. So if theminimum delay was t seconds, the actual delay would satisfy:

[0329] t<=actual-wait<=t+Δt

[0330] The MinDelay statements divide up the Levels specification into anumber of subsequences, each of which will require separate TestCondition Memory settings for processing.

[0331] Each pin or pin-group name is specified in exactly one resourcein a pin description file (suffix pin), and therefore has a certain setof viable resource parameters specified in the resource file (suffix.rsc). All the parameters named must be from among this set of viableresource parameters, and must be of the same elementary type as theexpression used to set their value. Information about the names andtypes of resource parameters comes from the resource file.

[0332] The resource file Resources.rsc is implicitly imported, providingtester with the names and types for parameters of standard resourcessuch as dpin, and dps.

[0333] Resource parameters are assigned expressions that can useUserVars, and values from named specification sets or a currentlyvisible local specification set.

[0334] Dps pin resources have special parameters PRE_WAIT and POST_WAIT.The PRE_WAIT parameter specifies the time that needs to elapse from thetime the power pin has reached its destination voltage to the timepattern generation can start. The POST_WAIT parameter specifies the timethat needs to elapse from the time pattern generation has stopped to thetime the power pin shuts off.

[0335] Dps pins also specify how the voltage parameter reaches its finalvalue. They could specify it simply by an equation, as all other pinparameters. In that case the value will be reached as the hardwareallows it. They could also specify it using a Slew statement. A Slewstatement specifies that the power supply voltage reaches its finalvalue from the initial value in a ramp with a specified absolute VoltageSlew Rate.

[0336] C++ for Levels

[0337] With above rules, a C++ Levels object can be written thatsupports the following operations:

[0338] There is an operation

[0339] Status setParameter(const String& pinOrPinGroupName, constString& parameterName, ElementaryType elementaryType, const Expression&Expression);

[0340] This operation binds an expression to a parameter of a pin or apin group. For instance, the dpin.InPins VIH value is set by:

[0341] setParameter(“InPins”, “VIH”, VoltageT, Expression(“v_ih+1.0);

[0342] This operation will be called several times for all thedeclarations in the Levels object.

[0343] There is an operation

[0344] Status assignlevels(const String& selector);

[0345] which will go through and issue all the predetermined modulelevel interfaces to assign all the levels of parameters in specificationorder, as described earlier. The selector parameter is used to resolvenames in the expressions according to the rules specified earlier.

[0346] Test Condition Groups

[0347] The Test Condition Group Sub-language packages together thedescription of specifications, timings and levels. Timing objects areoften specified using parameters. Parameters can be used in timings tospecify leading and trailing edges of various pulses. Likewise, Levelscan be parameterized by specifying maximum, minimum and typical valuesof various voltage levels. A Test Condition Group (TCG) object lumpstogether the specifications and the instantiation of Timings and Levelsbased on these specifications.

[0348] A TestConditionGroup declaration contains an optionalSpecificationSet. The SpecificationSet declaration may be an inlined(and unnamed) local SpecificationSet, or it may be a reference to anamed SpecificationSet declared elsewhere. The optional SpecificationSetdeclaration in a TCG declaration is followed by at least one Levels orTimings declaration. It can have both Levels and a Timings, in anyorder. However, it is disallowed from having more than one Levels andTimings declaration. These restrictions are syntactically enforced.

[0349] A specification set declaration in a TCG is identical to thespecification set declared separately, except that it does not have aname. Its name is implicitly the name of the enclosing TCG. The Timingsdeclaration comprises a single declaration of a Timings object from aspecified timings file. Here is an example of a file with a testcondition group: #--------------------------------------------------------- # FilemyTestConditionGroups.tcg #--------------------------------------------------------- Version 0.1;Import pentiumlevels.lvl; Import edges.spec; Import timing1.tim; Importtiming2.tim; TestConditionGroup TCG1 { # This Local SpecificationSetuses user-defined selectors # “min”, “max” and “typ”. Any number ofselectors with any # user defined names is allowed. # # Thespecification set specifies a table giving values for # variables thatcan be used in expressions to initialize # timings and levels. Thespecification set below defines # values for variables as per thefollowing table: # min max typ # v_cc 2.9 3.1 3.0 # v_ih vInHigh +0.0 vInHigh + 0.2 vInHigh + 0.1 # v_il vInLow + 0.0 vInLow + 0.2vInLow + 0.1 # ... # A reference such as “vInHigh” must be previouslydefined # in a block of UserVars. # #Thus, if the “max” selector wasselected in a functional # test, then the “max” column of values wouldbe bound to # the variables, setting v_cc to 3.1, v_ih to vInHigh+2.0 #and so on. # # Note that this is a local specification set, and has no #name. SpecificationSet(min, max, typ) { # Minimum, Maximum and Typicalspecifications for # voltages. V ltage v_cc = 2.9, 3.1, 3.0; Voltagev_ih = vInHigh + 0.0, vInHigh + 0.2, vInHigh + 0.1; Voltage v_il =vInLow + 0.0, vInLow + 0.2, vInLow + 0.1; # Minimum, Maximum and Typicalspecifications for # leading and trailing timing edges. The base # valueof 1.0E−6 uS corresponds to 1 picosecond, # and is given as an exampleof using scientific # notation for numbers along with units. Time t_le =1.0E−6 uS, 1.0E−6 uS + 4.0 * DeltaT, 1.0E−6 uS + 2.0 * DeltaT; Time t_te= 30ns, 30ns + 4.0 * DeltaT, 30ns + 2.0 * DeltaT; } # Refers to thePentium3Levels imported earlier. It # is one of possibly many levelsobjects that have been # imported from the above file. LevelsPentium3Levels; # Refers to file timing1.tim containing the single #timing Timing1. The filename should be quoted if # it has whitespacecharacters in it. Timings Timing1; } # Another test condition groupTestConditionGroup TCG2 { # ClockAndDataEdgesSpecs is a specificationset which # is available in the edges.specs file. Assume it has # thefollowing declaration: # SpecificationSet ClockAndDataEdgesSpecs(min,max, typ) # { # Time clock_le = 10.00 uS, 10.02 uS, 10.01 uS; # Timeclock_te = 20.00 uS, 20.02 uS, 20.01 uS; # Time data_le = 10.0 uS, 10.2uS, 10.1 uS; # Time data_te = 30.0 uS, 30.2 uS, 30.1 uS; # } # ASpecificationSet reference to this named set is below: SpecificationSetClockAndDataEdgesSpecs; # An inlined levels declaration. Since theassociated # specification set (above) does not have variables such # asVInLow, VInHigh, VOutLow and VOutHigh, they must # resolve in thedefault UserVars collection. Levels { InPins { VIL = VInLow; VIH =VInHigh + 1.0; } OutPins { VOL = VOutLow / 2.0; VOH = VOutHigh; } } #This Timing is from the file “timing2.tim”. The timings # will need theleading and trailing edge timings for clock # and data as specified inthe above specification set. Timings Timing2; }

[0350] In the above example, the test condition group TCG1 describes aspecification set with three selectors named “min”, “typ” and “max”.There can be any number of distinct selectors. Within the body of thespecification set, variables v_il, v_ih, t_le and t_te are initializedwith triples of values, corresponding to the selectors. So in the aboveexample, an instance of TCG1 with the selector “min” will bind thevariable v_il with the first numeric value, (vInputLow+0.0). It bearsrepetition that the selectors for a specification set are user defined,and any number of them is allowed. The only requirement is that:

[0351] The selectors of a specification set be unique identifiers.

[0352] Each value specified in the specification set is associated withan array of values that exactly the same number of elements as the setof selectors. Picking the i^(th) selector will cause each value to bebound to the i^(th) value of its associated vector of values.

[0353] Subsequent to the specification set in the TCG, there could be aLevels declaration or a Timings declaration or both. The Levelsdeclaration is used to set levels for various pin parameters. Thevariables identified in the specification set will be used to set theselevels, permitting a dynamic binding of different actual values for pinparameters based on the selector used to initialize the TCG.

[0354] To exemplify this, consider a Test that enables the selector“min”. Referring to the specification set Pentium3Levels given on page,the pin parameter “VIH” for pins in the InPins group will be initializedto the expression (v_ih+1.0) by the declaration:

[0355] InPins{VIL=v_il; VIH=v_ih+1.0;}

[0356] This resolves to (VInHigh+0.0+1.0) when the selector “min” isenabled. Likewise, the Timings object can be initialized based on theselected values of the specification set variables. It is not necessaryto have both a Timings and a Levels declaration. Either can be presentby itself, or both in any order, as illustrated by the followingexample: # --------------------------------------------------------- #File LevelsOnlyAndTimingsOnly.tcg #--------------------------------------------------------- Version 0.1; #A Levels-only Test Condition Group. TestConditionGroup LevelsOnlyTCG {SpecificationSet(Min, Max, Typ) { Voltage v_il = 0.0, 0.2, 0.1; Voltagev_ih = 3.9, 4.1, 4.0; } # An inlined levels declaration. Since theassociated # specification set (above) does not have variables such # asVInLow, VInHigh, VOutLow and VOutHigh, they must # resolve in thedefault UserVars collection. Levels { InPins { VIL = v_il; VIH = v_ih +1.0; } OutPins { VOL = v_il / 2.0; VOH = v_ih; } } } # A Timings-onlyTest Condition Group TestConditionGroup TimingsOnlyTCG {SpecificationSet(Min, Max, Typ) { Time t_le = 0.9E−3, 1.1E−3, 1.0E−3; }Timings Timing2; }

[0357] Note, however, there should not be more than one Timings and morethan one Levels in a TCG. Thus, in summary, there should be at least oneof Timings or Levels, and at most one of each.

[0358] Test Conditions

[0359] A TestCondition object ties a TCG to a specific Selector. Once aTCG has been declared as shown above, it is possible to declareTestCondition objects as shown below: TestCondition TCMin {TestConditionGroup = TCG1; Selector = min; } TestCondition TCTyp {TestConditionGroup = TCG1; Selector = typ; } TestCondition TCMax {TestConditionGroup = TCG1; Selector = max; }

[0360] These Test Conditions would be instantiated in a Test Plan asfollows: # # Declare a FunctionalTest “MyFunctionalTest” that refers tothree # Test Condition Group instances. # Test FunctionalTestMyFunctionalTest { # Specify the Pattern List PList = pat1Alist; # Anynumber of TestConditions can be specified: TestCondition =TCMin;TestCondition = TCMax; TestCondition = TCTyp; }

[0361] Name Resolution in TCGs (Test Condition Groups)

[0362] Resolution of names in a test condition group was discussedearlier. However, these rules bear repetition, and are given belowagain:

[0363] 1. If the name is qualified (cf. page), it must be resolved in anamed user variables collection.

[0364] 2. If the name is not qualified, the name is resolved in either alocal specification set, if it is declared in the test condition group,or in the named specification set, if one is referenced in the testcondition group.

[0365] 3. If the name is not resolved by the earlier rules, it isresolved in the default user variables collection.

[0366] TCG Runtime

[0367] Test condition groups have the following runtime semantics:

[0368] A Test (such as a FunctionalTest) will reference a TCG with aparticular selector from its SpecificationSet, using an instantiatedTestCondition. This selector will bind each variable in theSpecificationSet to its value associated with the chosen selector. Thisbinding of variables to their values will then be used to determineLevels and Timings.

[0369] Parameter Levels in a TestConditionGroup are preferably setsequentially, in the order of presentation in the Levels block. So inthe Pentium3Levels block, the order in which parameter levels would beset is as follows (notation: <resource-name>.<resource-parameter>):

[0370] InputPins.VIL,

[0371] InputPins.VIH,

[0372] OutputPins.VIL,

[0373] OutputPins.VIH,

[0374] Clock.VOL,

[0375] Clock.VOH.

[0376] This sequencing order enables the test writer to control theexplicit power sequencing of power supplies. Furthermore, if a levelsitem occurs twice, naming the same pin-parameters for a pin, then thatpin-parameter gets set twice. This can happen programmatically also.

[0377] If a parameter is set by a Slew statement such as

[0378] VCC=Slew(0.01, 2.0 V);

[0379] it means that VCC will reach its final value of 2.0 volts fromits present value in a ramp with a Voltage Slew Rate of ±0.01 volts persecond.

[0380] Specification set variables can also be passed into a Timingsobject in the TCG. The Timings object will then be initialized based onthe selected variables. Such a mechanism could be used to customize aTimings object, as, for instance, by specifying leading and trailingedges of waveforms.

[0381] C++ for TCGs

[0382] With the above rules, the Test Condition Group can be declared ina C++ TestConditionGroup class, and initializing it as follows:

[0383] A call is made to the TestConditionGroup member function

[0384] Status setSpecificationSet(SpecificationSet pSpecificationSet);

[0385] which will set the specification set for the TestConditionGroup.This may either be a local specification set, or a named specificationset, or null (if there is none).

[0386] A call is made to the TestConditionGroup member function

[0387] Status setLevels(Levels *pLevels);

[0388] which will set the Levels object for the TestConditionGroup. Thismay either be a locally declared levels object, or an externallydeclared levels object, or null (if there is none).

[0389] A call is made to the TestConditionGroup member function

[0390] Status setTimings(Timings *pTimings);

[0391] which will set the Timings object for the TestConditionGroup.This will be either an externally declared Timings object, or null (ifthere is none).

[0392] Bin Definitions

[0393] The Bin Definitions class defines bins, a collection of countersthat summarize the results of testing many DUTs. During the course oftesting a DUT, the DUT can be set to any bin, e.g., to indicate theresult of a particular test. As testing proceeds, the DUT may be set toanother bin. The bin that the DUT is finally set to is the last suchsetting at the end of the test. The counter for this final bin isincremented at the end of the test of this DUT. A separate file with bindefinitions should have the suffix .bdefs.

[0394] Bin definitions are preferably hierarchical. For example, at anoutermost level, there may be the PassFailBins with two bins named Passand Fail. Then there could be several HardBins, some of which map to thePass bin, and others which map to the Fail bin. The HardBins are said tobe a refinement of the PassFailBins. Finally, there could be a largenumber of SoftBins, a refinement of HardBins, many of which map to thesame Hard bin. Below is an example illustrating the hierarchy of bins: #--------------------------------------------------------- # Filepentiumbins.bdefs #--------------------------------------------------------- Version 1.2.3;BinDefs { # The HardBins are an outermost level of # bins. They are nota refinement of any other # bins. BinGroup HardBins { “3GHzPass”: “DUTspassing 3GHz”; “2.8GHzPass”: “DUTs passing 2.8GHz”; “3GHzFail”: “DUTsfailing 3GHz”; “2.8GHzFail”: “DUTs failing 2.8GHz”; LeakageFail: “DUTsfailing leakage”; } # The SoftBins are a next level of refinement. #SoftBins are a refinement of HardBins. BinGroup SoftBins : HardBins {“3GHzAllPass”: “Good DUTs at 3GHz”, “3GHzPass”; “3GHzCacheFail”: “CacheFails at 3GHz”, “3GHzFail”; “3GHzSBFTFail”: “SBFT Fails at3GHz”, “3GHzFail”; “3GHzLeakage”: “Leakages at 3GHz”,  LeakageFail;“2.8GHzAllPass”: “Good DUTs at 2.8GHz”,“2.8GHzPass”; “2.8GHzCacheFail”“Cache Fails at 2.8GHz”,“2.8GHzFail”; “2.8GHzSBFTFail”: “SBFT Fails at2.8GHz”, “2.8GHzFail”; “2.8GHzLeakage”: “Leakages at2.8GHz”, LeakageFail; } }

[0395] In the above example, the most base bins are the BinGroupHardBins. A BinGroup X is said to be a group of base bins if some otherBinGroup is a refinement of X. Thus, the BinGroup HardBins is a group ofbase bins since the BinGroup SoftBins is a refinement of HardBins. Thebins of SoftBins are referred to as leaf bins. A BinGroup Y is said tobe a group of leaf bins if no other BinGroup is a refinement of Y.

[0396] The degenerate case of a BinDefs block with a single BinGroup Zin it will have Z to be a group of most base bins, as well as a group ofleaf bins. BinGroup names are global in scope. There can be any numberof BinDefs blocks, but the declared BinGroups must be distinct. ABinGroup from one BinDefs block is allowed to be a refinement of aBinGroup from another BinDefs block. So in the above example, SoftBinscould be in a separate BinDefs block from HardBins. However, it isstrongly recommended to have a single BinDefs block with all theBinGroups defined for the sake of readability.

[0397] The above hierarchy can now be extended to count how many DUTspassed and failed, by adding another BinGroup. #---------------------------------------------------------- # Filepentiumbins.bdefs #---------------------------------------------------------- Version1.2.3; BinDefs { # The PassFailBins are an outermost level of # bins.They are not a refinement of any other # bins. BinGroup PassFailBins {Pass: “Count of passing DUTS.”; Fail: “Count of failing DUTS.”; } # TheHardBins are a next level of refinement. # HardBins are a refinement ofthe PassFailBins, # as indicated by “HardBins : PassFailBins”. BinGroupHardBins : PassFailBins { “3GHzPass”: “DUTs passing 3GHz”, Pass;“2.8GHzPass”: “DUTs passing 2.8GHz”, Pass; “3GHzFail”: “DUTs failing3GHz”, Fail; “2.8GHzFail”: “DUTs failing 2.8GHz”, Fail; LeakageFail:“DUTs failing leakage”, Fail; } # The SoftBins are a next level ofrefinement. # SoftBins are a refinement of HardBins. BinGr up SoftBins :HardBins { “3GHzAllPass”: “Good DUTs at 3GHz”, “3GHzPass”;“3GHzCacheFail”: “Cache Fails at 3GHz”, “3GHzFail”; “3GHzSBFTFail”:“SBFT Fails at 3GHz”, “3GHzFail”; “3GHzLeakage”: “Leakages at 3GHz”, LeakageFail; “2.8GHzAllPass”: “Good DUTs at 2.8GHz”,“2.8GHzPass”;“2.8GHzCacheFail”: “Cache Fails at 2.8GHz”,“2.8GHzFail”;“2.8GHzSBFTFail”: “SBFT Fails at 2.8GHz”, “2.8GHzFail”; “2.8GHzLeakage”:“Leakages at 2.8GHz”, LeakageFail; } }

[0398] This time, the most base bins are the BinGroup PassFailBins. Theyare typically not a refinement of any bins. The BinGroup HardBins are arefinement of the PassFailBins and are also base bins. SoftBins are arefinement of the HardBins, and are a group of leaf bins. The aboveexample had only three BinGroups in the hierarchy.

[0399] Below is a more complicated hierarchy: BinDefs { # A group ofmost base bins BinGroup A {...} # A group of base bins that is arefinement of A BinGroup Ax : A {...} # A group of leaf bins that is arefinement of Ax BinGroup Axx : Ax {...} # A group of base bins that isa refinement of A BinGroup Ay : A {...} # A group of leaf bins that is arefinement of Ay BinGroup Ayy : Ay {...} # A group of most base binsBinGroup B {...} # A group of leaf bins that is a refinement of BBinGroup Bx : B {...} }

[0400] In this example, Ax and Ay are refinements of A, Axx is arefinement of Ax and Ayy is a refinement of Ay. This example alsoprovides BinGroups B and Bx where Bx is a refinement of B. The BinDefsdeclaration above with the BinGroups named PassFailBins, HardBins andSoftBins will be used as a continuing example in this section.

[0401] Each bin in a BinGroup has:

[0402] 1. a name which is either an identifier or a string literal

[0403] 2. a description which describes what this bin summarizes

[0404] 3. and if this bin is in a refinement BinGroup, the name of thebin it is a refinement of, also known as the base bin.

[0405] The two bins in PassFailBins are named “Pass” and “Fail”. Thefive bins in HardBins are named “3 GHzPass”, “2.8 GHzPass”, “3 GHzFail”,“2.8 GHzFail”, “LeakageFail”. Bin names may be a literal string, or anidentifier. Bin names must be unique in a BinGroup, but may beduplicated across BinGroups. BinGroup names, however, are global inscope, and must be unique across a test plan.

[0406] Of the five HardBins, the bins “3 GHzPass” and “2.8 GHzPass” bothmap to the “Pass” bin of the PassFailBins. The rest of the HardBins mapto the “Fail” bins of the PassFailBins.

[0407] Finally, there are eight SoftBins. The two failures at 3 GHz forSBFT (soft bin functional test) and Cache map to the “3 GHzFail”HardBin. Likewise the two failures at 2.8 GHz for SBFT and Cache map tothe “2.8 GHzFail” HardBin. Both the failures due to Leakage map to thesame “LeakageFail” HardBin, regardless of the speed at which theyoccurred. For example, the coarsest test (at the outermost level) iswhether a DUT passes or fails a test. A refinement is, for example,whether the DUT passes or fails a test at a particular frequency, e.g.,3 GHz, etc.

[0408] Bins are assigned to DUTs in a Test Plan FlowItem, describedbelow. A TestPlan FlowItem has a Result Clause in which the test plandescribes the actions and transition to take place as the result ofgetting a particular result back from executing a test. It is at thispoint that a SetBin statement can occur: # A FlowItem Result clause. Itis described later. Result 0 { # Action to be taken on getting a 0 backfrom # executing a test. # Set the bin to SoftBin.“3GHZPass” expressingthat the # DUT was excellent. SetBin SoftBins.“3GHzPass”; }

[0409] Many SetBin statements could execute during the course of runninga test on a DUT. When the test is finally completed, the runtime willincrement counters for the final bin that is set for that DUT, and forall its refinements. Consider a DUT which had the following SetBinstatements executed during the course of its test:

[0410] SetBin SoftBins.“3 GHzSBFTFail”;

[0411] SetBin SoftBins.“2.8 GHzAllPass”;

[0412] This DUT passed the 3 GHz Cache and Leakage tests, but failed theSBFT test, and so was assigned to the “3 GHzSBFTFail” bin. It was thentested at 2.8 GHz, and all the tests passed. So the final bin assignmentis to the “2.8 GHzAllPass” bin, which is in the set of SoftBins. Thisfinal assignment will increment the counters of the following bins:

[0413] 1. SoftBins.“2.5 GHzAllPass”

[0414] 2. which is a refinement of HardBins.“2.8 GhzPass”

[0415] 3. which is a refinement of PassFailBins.“Pass”

[0416] When the test completes, runtime will increment the counter ofthe final bin assignment of the DUT, and for all other bins it is arefinement of.

[0417] A SetBin statement is allowed only on a leaf bin. It is illegalto set a base bin. The counter incrementing semantics above assuresthat:

[0418] 1. If the bin is a leaf bin, it is the number of times a SetBinstatement was executed for this bin at the end of testing a DUT.

[0419] 2. If the bin is a base bin, it is the sum of the counters of thebins that it is a refinement of.

[0420] Thus, in the above example, only SoftBins are allowed in a SetBinstatement. The counter for HardBins.“LeakageFail” is the sum of thecounters for SoftBins.“3 GHzLeakageFail” and SoftBins.“2.8GHzLeakageFail”. Below are some rules regarding bin definitions:

[0421] 1. A BinDefinitions declaration is comprised of several BinGroupdeclarations.

[0422] 2. Each BinGroup declaration has a name, an optional BinGroupname that it is a refinement of, followed by a block of bindeclarations.

[0423] 3. Bin declarations comprise a name, followed by a description,optionally followed by the name of a base bin that this bin is arefinement of.

[0424] 4. Bin names can be a string literal, or an Id. The empty stringshould not be a valid bin name. Bin names should be unique among namesin the BinGroup declaration, but the same name could be used in otherBinGroup declarations.

[0425] 5. If a BinGroup declaration Xxx is a refinement of anotherBinGroup declaration Yyy, then all of the bin declarations in Xxx mustdeclare the name of a base bin from Yyy. Thus, each of the bindeclarations in SoftBins is a refinement of a bin of HardBins, since theSoftBins are declared to be a refinement of HardBins.

[0426] 6. A BinGroup declaration that is not a refinement of anotherBinGroup declaration, such as PassFailBins will preferably have Bindeclarations that do not declare base bins.

[0427] A bin Bbb has a set of bases which is the entire set of bins thatBbb is a refinement of. It is formally defined as follows:

[0428] 1. If Aaa is the base bin of Bbb, then Aaa is in the set of basesof Bbb.

[0429] 2. Any base of Aaa is also in the set of bases of Bbb.

[0430] BinGroup names are global in a TestPlan.

[0431] Bin names are local to a BinGroup.

[0432] A SetBin statement is only allowed for a leaf bin.

[0433] C++ for Bin Definitions

[0434] With above rules, an object type BinGroup can be constructed foreach of the BinGroup declarations in the BinDefs declaration. The classBinGroup will have a subclass LeafBinGroup. The operations of these twoclasses are the same, except that BinGroup::incrementBin is a C++protected operation, whereas LeafBinGroup::incrementBin is a C++ publicoperation.

[0435] The following is a default constructor which builds a BinGroup ora LeafBinGroup which is not a refinement of any other BinGroup.

[0436] Constructors:

[0437] BinGroup(BinGroup& baseBinGroup);

[0438] LeafBinGroup(BinGroup& baseBinGroup);

[0439] that builds a BinGroup that is a refinement of the givenbaseBinGroup.

[0440] A method

[0441] Status addBin(const String& binName,

[0442] const String& description,

[0443] const String& baseBinName);

[0444] to define a bin and its description. If it is a most base bin,the baseBinName parameter must be the empty string.

[0445] Methods to increment bin counters:

[0446] Status incrementbin(const String& binName);

[0447] This operation will increment the counter for this bin, and forall bins that are bases of this bin. The operation is protected in theclass BinGroup, and is public in the class LeafBinGroup.

[0448] Methods to reset bin counters

[0449] Status resetbin(const String& binName);

[0450] This operation will reset the counter for this bin, and for allbins that are the bases of this bin.

[0451] Methods to get information about a bin:

[0452] Status getBinDescription(const String& binName, String&description);

[0453] Status getBaseBin(const String& binName, BinGroup*pBaseBinGroup,String& baseBinName);

[0454] Status getBinValue(const String& binName, unsigned int& value);

[0455] Iterators will be provided to get at all the currently definedbin names.

[0456] TestPlan state will be include number of BinGroup members, onefor each BinGroup declaration. The C++ for the above BinDefinitionswould be as follows: // TestPlan constructor TestPlan::TestPlan() :m_PassFailBins(),// Default Constructor   m_HardBins(&m_PassFailBins),  m_SoftBins(&m_HardBins) { } // Bin initializationsm_PassFailBins.addBin(“Pass”,“Count of passing DUTS.”,“”);m_PassFailBins.addBin(“Fail”,“Count of failing DUTS.”,“”);m_HardBins.addBin(“3GHzPass”, “Duts passing 3GHz”,“Pass”); ...

[0457] State for a TestPlan includes a m_pCurrentBinGroup which isinitialized to the undefined BinGroup (NULL) and the m_currentBinundefined bin name (the empty string). Each time a SetBin statement isexecuted, the m_pCurrentBinGroup is changed to the indicated the namedBinGroup and the m_currentBin to the named bin in the group by a call:// Translation of: SetBin SoftBins.“3GHzAllPass”;pTestPlan->setBin(“SoftBins”,“3GHzAllPass”); When the test plancompletes execution, it will callm_pCurrentBinGroup−>incrementBin(m_currentBin);

[0458] causing this bin and all its base bins to have their countersincremented.

[0459] The BinGroup counters are reset when the test plan is elaborated,but are not reinitialized each time a test is run. The counters can bereset by an explicit call to BinGroup::resetBin.

[0460] C. The Test Plan

[0461] The test plan can be thought of as a main structure of the testprogram. The Test Plan can import files, as well as define similarconstructs inline. Thus, it is possible to import a file givendefinitions of some globals, as well as declaring additional globalsinline.

[0462] C1. Test Plan Flows and FlowItems

[0463] One of the critical elements of the Test Plan is the Flow. A Flowencapsulates a finite state machine. It comprises several FlowItemswhich run an IFlowable object and then transition to another flow item.Running an IFlowable involves running an object that implements theIFlowable interface. Typical objects that implement the IFlowableinterface are Tests and Flows themselves.

[0464] Thus, a Flow has FlowItems which runs Tests and other Flows, andthen transition to another FlowItem. It also provides for theopportunity to call user customized routines on various return resultsfrom running an IFlowable. Typically, a Flow thus has the followingform: # # FlowTest1 implements a finite state machine for the # Min, Typand Max flavors of MyFunctionalTest1. On # success it tests Test1Min,Test1Typ, Test1Max # and then returns to its caller with 0 as asuccessful # status. On failure, it returns 1 as a failing status. # #Assume that the tests MyFunctionalTest1Min, ... all # return a Result of0 (Pass), 1 and 2 (for a couple # of levels of failure). # Result 0Result 1 Result 2 # Test1Min Test1Typ return 1 return 1 # Test1TypTest1Max return 1 return 1 # Test1Max return 0 return 1 return 1 # FlowFlowTest1 { FlowItem FlowTest1_Min MyFunctionalTest1Min { Result 0 {Property PassFail = “Pass”; IncrementCounters PassCount; GoToFlowTest1_Typ; } Result 1 { Property PassFail = “Fail”;IncrementCounters FailCount; Return 1; } # This result block will beexecuted if # MyFunctionalTest1Min returns any of # 2, 5, 6, 7, −6, −5or −4 Result 2, 5:7, −6:−4 { Property PassFail = “Fail”;IncrementCounters FailCount; Return 1; } } FlowItem FlowTest1_Typ {...}Fl wItem FlowTest1_Max {...} }

[0465] The operation of the Flow FlowTest1 is as follows:

[0466] 1. Starts up with executing FlowItem FlowTest1_Min.

[0467] 2. FlowTest1_Min runs a functional test, MyFunctionalTest1Min.Details of this test are provided when the complete test plan ispresented below.

[0468] 3. Nine results are expected from running this test, 0, 1, 2, 5,6, 7, −6, −5 or −4. The first two Result clauses handle 0 and 1respectively, and the third handles all the rest of the result values.

[0469] 4. If result “0” (pass) occurs, then FlowTest1_Min will incrementthe counter PassCounter. It will then transition to a new FlowItemFlowTest1 Typ.

[0470] 5. If result “1” or result “2” occurs, then FlowTest1_Min willincrement the counter FailCounter, and return from the flow.

[0471] 6. FlowTest1_Typ will operate in the same way, and on successcall FlowTest1_Max.

[0472] 7. FlowTest1_Max will operate in the same way, and on successreturn from FlowTest1 with a successful result (“0”).

[0473] Thus, FlowTest1 will, on a successful run, run a device throughthe minimum, typical and maximum versions of Test1, and then return.FlowTest2 will operate in a like manner.

[0474] A Flow as described above basically describes a Finite StateMachine with states and transitions. The FlowItems are basically states,which will do the following:

[0475] 1. Execute an IFlowable (it could be a previously defined Flow,or a Test, or a user defined Flow that can be implemented in C++ withthe above rules).

[0476] 2. Execution of the IFlowable return a numeric result. Based onthe result, certain actions occur (updating some counters), and then oneof two things happen:

[0477] a. The Flow returns to the caller with a numeric result.

[0478] b. The Flow continues by transitioning to another state(FlowItem).

[0479] Thus, a FlowItem has the following components:

[0480] A FlowItem has a name.

[0481] A FlowItem has an IFlowable to be executed.

[0482] A FlowItem has a number or Result clauses.

[0483] Each Result clause of a FlowItem provides actions and ends with atransition and is associated with one or more result values.

[0484] These items are syntactically as follows in a FlowItem. FlowItem<name> <IFlowable to be executed> { Result <one or more result values> {<actions for these result values> <transition for these result values> }Result <one or more other result values> { ... } ... }

[0485] The IFlowable to be executed could be either a Test, or aUser-defined IFlowable, or a Flow. The actions for a result could be anyof the following:

[0486] A Property Action to set string valued entities that are used byGUI tools to attribute results. This can be seen in the above FlowTest1example with:

[0487] Property PassFail=“Pass”;

[0488] Properties are basically named string or integer valued entitiesthat are associated with a Result clause. There can be any number ofthem, and they are preferably used by tools such as GUIs which a userwould use to display information associated with this result. They haveno effect on the actual result of the test, or the flow of the test.

[0489] A Counters Action to increment some number of counters. This canbe seen in the above example with:

[0490] IncrementCounters PassCount;

[0491] A Routine Call Action to call an arbitrary or user routine. Thisis discussed later.

[0492] Finally, a FlowItem has a Transition which could either be a GoTostatement to transfer control to another FlowItem, or a Return statementto transfer control back to the caller (either a calling flow, or thesystem routine which initiated the test plan).

[0493] Predefined Flows

[0494] The typical use of Flow objects is to define a sequence of Tests.This sequence is then executed as a result of an event occurring in aTest Plan Server (TPS), i.e. the Execute Test Plan event. A test planserver on each site controller executes the user's test plan. However,Flow objects are also executed in response to other events. The name inparentheses is the name used in assigning Flows to these events.

[0495] 1. System Load Flow (SysLoadFlow). This Flow is executed on theSystem Controller when a Test Plan is loaded onto one or more SiteControllers. It is executed prior to the actual loading of the Test Planon any Site Controller. This flow allows the Test Plan developer todefine actions that should originate from the System Controller. Suchactions include broadcast load of Pattern files, Calibration actions,etc.

[0496] 2. Site Load Flow (SiteLoadFlow). This Flow is executed on theSite Controller after a Test Plan has been loaded onto the Site andinitialized. This allows any Site-specific initialization to occur.

[0497] 3. Lot Start/End Flows (LotStartFlow/LotEndFlow). These Flowsexecute on the Site Controllers when the Test Plan Server is notified ofa start of a new lot. This is typically used in production environmentsto annotate datalog streams with lot-specific information.

[0498] 4. DUT Change Flow (DutChangeFlow). This Flow executes on theSite Controller when its DUT information changes. Again, this istypically used in production environments to update datalog streams.

[0499] 5. TestPlan Start/End Flows (TestPlanStartFlow/TestPlanEndFlow).These Flows execute on the Site Controller when the Test Plan Server isinstructed to start executing the current Test Flow and when that flowfinishes its execution.

[0500] 6. Test Start/End Flows (TestStartFlow/TestEndFlow). These Flowsexecute on the Site Controller when the Test Flow is starting to run anew Test and when that Test finishes its execution.

[0501] 7. Test Flow (TestFlow). This Flow is the main Flow objectexecuted when the Test Plan Server receives an “Execute Test Plan”message.

[0502] Note that if a user defines a Flow in the user's Test Plan thatis not the TestFlow or one of the other pre-defined flows, the preferredway to have it executed is to include it in the transition states of oneof these pre-defined flows.

[0503] A Test Plan Example

[0504] In the example below, Flows are given along with comments thatdescribe the finite state machine implemented by the flow. The finitestate machine is given as a transition matrix. Rows of the matrixcorrespond to FlowItems, and columns to the result. The entries of a rowof the matrix indicate the FlowItem that is transitioned to from theFlowItem of the row when the returned Result is the value specified inthe column.

[0505] A Test Plan with three flows, FlowTest1, FlowTest2 and FlowMain,is shown below. FlowTest1 will operate as described above. It will run atest named MyFunctionalTest1 in each of the “min”, “typ” and “max”configurations. Likewise, FlowTest2 will run MyFunctionalTest2 in eachof these configurations. Finally, FlowMain will run FlowTest1 andFlowTest2. The finite state machine transition matrix is provided incomments at the start of each of these flows. #--------------------------------------------------------- # FilemySimpleTestPlan.tpl #--------------------------------------------------------- Version 0.1;Import xxx.pin; # Pins # Constants and variables giving limiting values.Import limits.usrv; # Import test condition groups ImportmyTestConditionGroups.tcg; # Import some bin definitions. Importbins.bdefs; # ---------------------------------------------------------# Start of the test plan #--------------------------------------------------------- TestPlanSample; # This block defines Pattern Lists file-qualified names and #Pattern List variables that are used in Test declarations. # Patternlist variables are deferred till customization is # examined. PListDefs{ # File qualified pattern list names pl1A.plist:pat1Alist,pl2A.plist:pat2AList } # The socket for the tests in this test plan(this is not imported, # but resolved at activation time): SocketDef =mytest.soc; # Declare some user variables inline UserVars { # Stringname for current test String CurrentTest = “MyTest”; } Test ConditionTC1Min { TestConditionGroup = TCG1; Selector = min; } TestConditionTC1Typ { TestConditionGroup = TCG1; Selector = typ; } TestConditionTC1Max { TestConditionGroup = TCG1; Selector = max; } # Likewise forTC2Min, TC2Typ, TC2Max ... # # Declare a FunctionalTest.“FunctionalTest” refers to a C++ # test class that runs the test, andreturns a 0, 1 or 2 as # a Result. The Test Condition Group TCG1 isselected with # the “min” selector by referring to the TC1MinTestCondition. # Test FunctionalTest MyFunctionalTest1Min { PListParam =pat1AList; TestConditionParam = TC1Min; } # Another FunctionalTestselecting TCG1 with “typ” Test FunctionalTest MyFunctionalTest1Typ {PListParam = pat1AList; TestConditionParam = TC1Typ; } # AnotherFunctionalTest selecting TCG1 with “max” Test FunctionalTestMyFunctionalTest1Max { PListParam = pat1AList; TestConditionParam =TC1Max; } # Now select TCG2 with “min” Test FunctionalTestMyFunctionalTest2Min { PListParam = pat2AList; TestConditionParam =TC2Min; } # Likewise for TCG2 with “typ” and TCG2 with “max” TestFunctionalTest MyFunctionalTest2Typ { PListParam = pat1AList;TestConditionParam = TC2Typ; } Test FunctionalTest MyFunctionalTest2Max{ PListParam = pat1AList; TestConditionParam = TC2Max; } # # At thistime the following Test objects have been defined # MyFunctionalTest1Min# MyFunctionalTest1Typ # MyFunctionalTest1Max # MyFunctionalTest2Min #MyFunctionalTest2Typ # MyFunctionalTest2Max # # # Counters are variablesthat are incremented during the # execution of a test. They areUnsignedIntegers that are # initialized to zero. # Counters {PassCount,FailCount} # # Flows can now be presented. A Flow is an object that #essentially represents a finite state machine which # can execute“Flowables”, and transition to other flowables based # on the Resultreturned from executing a Flowable. A Flow can also # call another flow.# # A Flow consists of a number of Flow Items and transitions # betweenthem. FlowItems have names which are unique in # the enclosing Flow,execute a “Flowable” object, and then # transition to another FlowItemin the same enclosing Flow. # # Flowable objects include Tests and otherFlows. When # a Flowable object executes, it returns a numeric Result #which is used by the FlowItem to transition to another # FlowItem. As aresult of this, both Tests and Flows # terminate by returning a numericResult value. # # FlowTest1 implements a finite state machine for the #Min, Typ and Max flavors of MyFunctionalTest1. On # success it testsTest1Min, Test1Typ, Test1Max # and then returns to its caller with 0 asa successful # Result. On failure, it returns 1 as a failing Result. # #Assume that the tests MyFunctionalTest1Min, ... all # return a Result of0 (Pass), 1 and 2 (for a couple # of levels of failure). The TransitionMatrix of the # finite state machine implemented by FlowTest1 is: #----------------------------------------------------------- # Result 0Result 1 Result 2 #----------------------------------------------------------- #FlowTest1_Min FlowTest1_Typ return 1 return 1 # FlowTest1_TypFlowTest1_Max return 1 return 1 # FlowTest1 Max return 0 return 1 return1 # # where the IFlowables run by each FlowItem are: # FlowItemIFlowable that is run # FlowTest1_Min MyFunctionalTest1Min #FlowTest1_Typ MyFunctionalTest1Typ # FlowTest1_Max MyFunctionalTest1Max# Flow FlowTest1 { FlowItem FlowTest1_Min MyFunctionalTest1Min { Result0 { Property PassFail = “Pass”; IncrementCounters PassCount; GoToFlowTest1_Typ; } Result 1,2 { Property PassFail = “Fail”;IncrementCounters FailCount; Return 1; } } FlowItem FlowTest1_TypMyFunctionalTest1Typ { Result 0 { Property PassFail = “Pass”;IncrementCounters PassCount; GoTo FlowTest1_Max; } Result 1,2 { PropertyPassFail = “Fail”; IncrementCounters FailCount; Return 1; } } # Likewisefor FlowTest1_Max FlowItem FlowTest1_Max MyFunctionalTest1Max { Result 0{ Property PassFail = “Pass”; IncrementCounters PassCount; Return 0; }Result 1,2 { Property PassFail = “Fail”; IncrementCounters FailCount;Return 1; } } } # # FlowTest2 is similar to FlowTest1. It implements a #finite state machine for the Min, Typ and Max flavors # ofMyFunctionalTest2. On success it tests Test2Min, # Test2Typ, Test2Maxand then returns to its caller with # 0 as a successful Result. Onfailure, it returns 1 as # a failing Result. # # Assume that the testsMyFunctionalTest2Min, ... all # return a Result of 0 (Pass), 1 and 2(for a couple # of levels of failure). The Transition Matrix of the #finite state machine implemented by FlowTest2 is: #----------------------------------------------------------- # Result 0Result 1 Result 2 #----------------------------------------------------------- #FlowTest2_Min FlowTest2_Typ return 1 return 1 # FlowTest2_TypFlowTest2_Max return 1 return 1 # FlowTest2_Max return 0 return 1 return1 # # Where the IFlowables run by each FlowItem are: # FlowItemIFlowable that is run # FlowTest2_Min MyFunctionalTest2Min #FlowTest2_Typ MyFunctionalTest2Typ # FlowTest2_Max MyFunctionalTest2Max# Flow FlowTest2 { #... } # # Now the FlowMain, the main test flow, canbe presented. It # implements a finite state machine that callsFlowTest1 # and FlowTest2 as below: #------------------------------------ # Result 0 Result 1 #------------------------------------ # FlowMain_1 FlowMain_2 return 1 #FlowMain_2 return 0 return 1 # # Where the IFlowables run by eachFlowItem are: # FlowItem IFlowable that is run # FlowMain_1 FlowTest1 #FlowMain_2 FlowTest2 Flow FlowMain { # The first declared flow is theinitial flow to be # executed. It goes to FlowMain_2 on success, and #returns 1 on failure. FlowItem FlowMain_1 FlowTest1 { Result 0 {Property PassFail = “Pass”; IncrementCounters PassCount; GoToFlowMain_2;} Result 1 { # Sorry ... FlowTest1 failed Property PassFail = “Fail”;IncrementCounters FailCount; # Add to the right soft bin SetBinSoftBins.“3GHzSBFTFail”; Return 1; } } FlowItem FlowMain_2 FlowTest2 {Result 0 { # All passed! Pr perty PassFail = “Pass”; IncrementC untersPassCount; # Add to the right soft bin SetBin SoftBins.“3GHzAllPass”;Return 0; } Result 1 { #FlowTest1 passed, but FlowTest2 failed PropertyPassFail = “Fail”; IncrementCounters FailCount; # Add to the right softbin SetBin SoftBins.“3GHzCacheFail”; Return 1; } } } TestFlow =FlowMain;

[0506] The above test plan is structured as follows in a preferredorder:

[0507] 1. First, a version number is provided. This number is used toensure compatibility with the compiler version.

[0508] 2. Then, a number of imports are declared. These are variousfiles with declarations needed in order to resolve names used in thetest plan.

[0509] 3. Next, the Test Plan name is declared, after which come theinline declarations of the test plan.

[0510] 4. Next a set of PListDefs are declared. These includefile-qualified names naming GlobalPLists from the named files. They alsoinclude Pattern List variables. Pattern List variables are variablesthat can be initialized in custom flowables at execution time. Theyprovide a means of delaying binding tests to actual pattern lists untilruntime.

[0511] 5. Next, a set of UserVars is declared. These include a string.

[0512] 6. Some Counters are then declared, to determine the number oftests passed and failed. Counters are simply variables that areinitialized to zero, and incremented at IncrementCounter statements.They are different from Bins described earlier which have the semanticsthat only the currently set bin is incremented at the end of the test ofa DUT.

[0513] 7. Next, a series of Test Conditions is declared. Each of thesespecifies a Test Condition Group and a selector. In this example, theTest Condition Groups come from mytestconditionsgroups.tcg. However,they could have been inline in the test plan.

[0514] 8. Next, a series of Flowables or Tests is declared. Each of thisis known Test FunctionalTest which selects a Pattern List and a testcondition. Thus for instance, MyFunctionalTest1Max selects the testcondition TC1Max and a pattern list.

[0515] 9. Following this, three flows are declared, FlowTest1, FlowTest2and FlowMain. Flows run Flowables. Flowables include Tests (such asMyFunctionalTest1Max) and other flows (such as FlowTest1 and FlowTest2).Each of FlowTest1 and FlowTest2 run through the minimum, typical andmaximum versions of Test1 and Test2 respectively. The flow FlowMaincalls the earlier declared flows, FlowTest1 and then FlowTest2.

[0516] 10. Finally, the TestFlow event is assigned to the FlowMain Flow.Thus the flow FlowMain is the one that will be executed by this testplan when a user chooses to Execute this plan.

[0517] C++ for Flows

[0518] With the above rules, a C++ implementation can be done for mostof the elements, with the exception of the Flows themselves.

[0519] C++ for FlowItems

[0520] The C++ class to represent a FlowItem may have the followinginterface:

[0521] An operation

[0522] Status setFlowable(IFlowable*pIFlowable);

[0523] which will set the IFlowable that will be executed for thisFlowItem.

[0524] Once the FlowItem returns from the set of calls needed to executethis IFlowable, it will need to increment a list of counters dependingon the Result value. To this end, the FlowItem needs to have a vector ofcounters that is to be incremented. This is initialized by a call:

[0525] Status setCounterRefs(unsigned int result, CounterRefListcounterRefs);

[0526] Calling this sets up a vector of references to counters into theFlowItem, so that it can increment them once the IFlowable completesexecution. For example, the statement

[0527] IncrementCounters A, B, C; would preferably use the above call asfollows: // Somewhere earlier CounterRefList counters; ... // Code forResult clause //  Result 2, 3 {...} // of flowObject. counters.reset( );counters.add(&A); counters.add(&B); counters.add(&C);flowObject.setCounterRefs(2, counters); flowObject.setCounterRefs(3,counters);

[0528] A temporary CounterRefList object named counters is used.Initially counters.reset( ) is called, followed by a number ofcounters.add( ) calls to set up the counters list. This is then used tosetup the vector of counter addresses to be updated for result values 2and 3.

[0529] The FlowItem may then need to transition to another FlowItem on aparticular result:

[0530] Status setTransition(unsigned int result, FlowItem*pFlowItem);

[0531] Several such calls will naturally need to be made in the casethat a certain Result clause deals with many result values.

[0532] The FlowItem may need to return a result. This is done by:

[0533] Status setReturnResult(unsigned int result, unsigned intreturnResult);

[0534] For example, for the FlowItem FirstFlowItem in the previousexample, the above would be called with the value “2” for “result” and“1” for “returnResult”.

[0535] Finally, the FlowItem needs an operation to execute:

[0536] Status execute(unsigned int& result, FlowItem*pNextFlowItem);

[0537] This operation will execute the IFlowable, then update theindicated counters, and then either return a Result, or a pointer to thenext FlowItem. If this pointer is NULL, then the result is the returnedvalue.

[0538] The code that would be generated for FlowItem FlowMain_(—)1 is asfollows: FlowItem FlowMain_1; FlowItem FlowMain_2; CounterRefListcounters; FlowMain_1.setFlowable(FlowTest1); // Result 0 counters.reset(); counters.add(&PassCount); FlowMain_1.setCounterRefs(0, counters);FlowMain_1.setTransition(0, &FlowMain_2); // Result 1 counters.reset( );counters.add(&FailCount); FlowMain_1.setCounterRefs(1, counters); // Thefollowing call from ITestPlan will set the // current bin group and binname. pTestPlan−>setBin(“SoftBins”,“3GHzSBFTFail”);FlowMain_1.setReturnResult(1, 1);

[0539] The code generated above sets up FlowMain_(—)1 to run theIFlowable “FlowTest1”, and then sets it up to increment the appropriatelist of counters for each result, and finally to take the necessaryactions. The necessary action in the case of result “0” is a transitionto FlowMain_(—)1, and in the case of result “1” is a return.

[0540] C2. Counter Support in a TestPlan

[0541] Counters are variables that are initialized to zero, and can beincremented by an IncrementCounter statement at various points during atest run. They are different from Bins, which are incremented only atthe end of the test. Furthermore, bins are hierarchical while countersare simple variables. Thus, counters are a much simpler and more limitedfacility than bins.

[0542] Counters can be supported in a TestPlan via a member of aCounters class that maintains a set of named counters which are unsignedintegers. Objects will be defined in this class via a Countersdeclaration. Counters will not be automatically reset when a teststarts, thus allowing a TestPlan to gather counts over testing manyDUTs. Methods will be provided to reset, increment and query the valueof a counter. This enables an alternative to binning in order todetermine counts as a result of running a test.

[0543] The TestPlan preferably contains a member variable,m_modifiedCounters, which is the set of counters modified by running thetest on a DUT. This set is initialized to the empty set at the start ofthe test. At each place an IncrementCounters call is made, code will begenerated to add the named counters to the m_modifiedCounters member.Thus, this member gathers together all the counters that were modifiedduring the execution of a test on a DUT.

[0544] C++ for the Flow Object

[0545] Once all the FlowItems have been created, the Flow object can becreated as a C++ object as shown below:

[0546] An operation to add a FlowItem

[0547] Status addFlowItem(FlowItem*pflowItem, bool is InitalFlowItem);

[0548] which will add the indicated FlowItem to the Flow. The boolean isset to True if this is the initial FlowItem of the Flow.

[0549] An operation to execute the Flow

[0550] Status executeFlow(unsigned int& result);

[0551] This will preferably return when the Flow returns, with theresult of executing the flow. The action of this is to start executingthe flow with the initial FlowItem. It will keep executing FlowItems aslong as the current FlowItem returns a next FlowItem to execute. Whenthe current FlowItem returns a Result, then this operation completeswith that Result.

[0552] Hence, the C++ code generated for a Flow has several repeatedcalls to addFlowItem( ) in order to add FlowItems to the Flow. TheexecuteFlow( ) operation will occur when this Flow in the Test Plan isselected for execution.

[0553] C3. Test Classes

[0554] In general majority of the program code is data for device test,and the rest is the code of test program, which realizes the testmethodology. This data is DUT-dependent (e.g., power supply conditions,signal voltage conditions, timing conditions, etc.). The test codeconsists of methods to load the specified device conditions on to ATEhardware, and also those needed to realize the user specified objectives(such datalogging, etc).

[0555] As explained above, to increase the reusability of test code,such code should be independent of any device-specific data (e.g., pinname, stimulus data, etc.), or device-test-specific data (e.g.,conditions for DC units, measurement pins, number of target pins, nameof pattern file, addresses of pattern programs, etc.). If code for atest is compiled with data of these types, the reusability of the testcode would decrease. Therefore, any device-specific data ordevice-test-specific data should be made available to the test codeexternally, as inputs during code execution time.

[0556] In the open architecture test system, a Test Class, which is animplementation of the ITest interface, realizes the separation of testdata and code (and hence, the reusability of code) for a particular typeof test. Such a test class could be regarded as a “template” forseparate instances of it, which differ from each other only on the basisof device-specific and/or device-test-specific data. Test classes arespecified in the test plan file. Each Test class typically implements aspecific type of device test or setup for device test. For example,Functional, AC and DC Parametric tests are preferably implemented byseparate Test classes. However, custom test classes can also be used intest plans.

[0557] Test classes allow the user to configure class behavior byproviding parameters that are used to specify the options for aparticular instance of that test. For example, a Functional Test willtake parameters PList and TestConditions, to specify the Pattern List toexecute, and the Level and Timing conditions for the test, respectively.Specifying different values for these parameters (through the use ofdifferent “Test” blocks in the test plan description file) allows theuser to create different instances of a Functional Test. FIG. 5 showshow different test instances 502 would be derived from a single testclass 504.

[0558] These classes should be designed to allow the compiler 400 totake the description of the tests and their parameters from the testplan file and generate correct C++ code, which can be compiled andlinked to generate the test program. Test class instances may be addedto objects describing test flow to create a complex execution sequenceof device tests.

[0559] C4. Derivation from ITest and IFlowable

[0560] As mentioned above, Test classes derive from ITest. With theabove rules, these can be implemented in C++ classes that implement theITest interface. In addition to the methods specified for the ITestinterface, these classes provide the Test-specific intelligence andlogic required to perform specific classes of device test. Test classesalso implement the IFlowable interface. As a consequence of this,instances of Test classes can be used in FlowItems to run tests.

[0561] Customization

[0562] Customization mechanisms are provided to allow users to call Cfunctions, and develop their own classes implementing the ITest andIFlowable interfaces.

[0563] Introspection Capability

[0564] If an object of a Test class could be interrogated regarding itsmethods and signatures, then it could be verified that the appropriateparameters are available for inclusion in the generated source code.Such a feature would be very useful for error checking and validationduring the translation phase. If the test engineer made a mistake in thenames of parameters, or the number (or possibly the types) of argumentsto these parameters, the translation phase could catch it and provide ameaningful error message at translation time instead of waiting for acompile-time error message from the C++ compiler. This would be moreuseful to the test engineer.

[0565] Introspection refers to the ability to ask an object to lookwithin itself and return information regarding its attributes andmethods. Some languages, such as Java, provide this ability as a part ofthe language. Other languages, such as Visual Basic, impose such arequirement on objects intended to be used with it. C++ makes noprovisions for this feature.

[0566] This method also lends well to providing for default parametervalues, as well as indications of optional parameters. In addition, ifthis capability is provided as a part of the implementation of all Testclasses, then GUI applications could also use this information todynamically build up dialogs and other user interface elements to helpengineers make effective use of these classes.

[0567] These complexities are offset in an embodiment of the inventionthrough a mechanism that provides, in lieu of full introspection, amethod that allows the Test class developer to fully specify, in asingle text-based source file (per Test class), the publicmethods/attributes of the Test class that the developer has designatedas the ones required to parameterize the class.

[0568] A single source is preferred: one would not want to have thedescription of the parameterization interface of a Test class in onefile, and the C++ interface description in another independent (header)file, and then be burdened with the need to keep both sourcessynchronized. Towards this end, the “text-based” description is embeddedin a pre-header file for the Test class, which is used by the compilerfor limited introspection, as well for generating the C++ header for theTest class. The generated C++ header file is the one used to finallycompile the Test class C++ code.

[0569] The Pre-Headers

[0570] The use of headers in C++ is well known. Because C++ is difficultto parse and read, however, an embodiment of the invention defines asyntax allowing the compiler to create a C++ output which can be used asa header by a test class developer. According to this embodiment, thetest class developer writes a pre-header, which is output by thecompiler 400 as a header file, allowing visibility into thecorresponding test classes or other test entities.

[0571] The following example illustrates the concept of the pre-headerfile for a Test class in accordance with the preferred embodiment of thepresent invention. Consider the following excerpt from a source file,with a test FuncTest1: ... TestConditionTC1 { TestConditionGroup = TCG1;# Previously defined TCG for Levels Selector = min; } TestCondition TC2{ TestConditionGroup = TCG2; # Previously defined TCG for TimingSelector = min; } ... Test FunctionalTest FuncTest1 { PListParam =patList1; # Previously defined pattern list TestConditionParam = TC1;TestConditionParam = TC2; }

[0572] The compiler needs to know what a FunctionalTest entails in orderto determine whether the declaration of FuncTest1 above is legal. Ratherthan building in the knowledge of a FunctionalTest into the compiler,the definition of what a FunctionalTest entails can be specified in thePre-Header.

[0573] Assume that FunctionalTest is a C++ class having base classesTest1 and Test2, and having members which are a PList, and an array ofTestConditions. The compiler needs to know about the types of themembers of FunctionalTest in order to recognize that the abovedeclaration of FuncTest1 is legal.

[0574] Furthermore, in order to generate a C++ object declaration forFuncTest1, a C++ header for the class FunctionalTest needs to beconstructed. This requires compiler to also know about the base classesof the FunctionalTest class, the names of its members and other suchinformation.

[0575] The pre-header sub-language of an embodiment of the inventionprovides the compiler with the information it needs to both recognizethe legality of declarations, and to generate C++ headers and objectdeclarations that correspond to declaration.

[0576] Note that a FunctionalTest is a simple type (as far asparameterization is concerned), and thus, would use quite a simpledescription for parameterization. One could thus write a pre-header,FunctionalTest.ph, that supports the above parameterization as follows(assume that pre-headers are available for the base test classes Test1and Test2):  1 Version 1.0;  2 #  3 # Parameterization specificationpre-header for FunctionalTest  4 #  5 Import Test1.ph; # For base classTest1  6 Import Test2.ph; # For base class Test2  7 TestClass =FunctionalTest; # The name of this test class  8 PublicBases =Test1,Test2; # List of public base classes  9 # The parameters list or“parameter block”: 10 Parameters 11 { 12 # The following declarationspecifies that a FunctionalTest has 13 #  - a parameter of typePList 14#  - [represented by C++ type Tester::PatternTree] 15 #  - stored in amember named m_pPatList 16 #  - a function to set it namedsetPatternTree. 17 #  - a parameter description for the GUI to use as atool tip 18 PList PListParam 19 { 20 Cardinality = 1 ; 21 Attribute =m_pPatList; 22 SetFunction = setPatternTree; 23 Description = “The PListparameter for a Functional Test”; 24 } 25 # 26 # The followingdeclaration specifies that a FunctionalTest has 27 #  - 1 or moreparameters of type TestCondition 28 #  - [represented by C++ typeTester::TestCondition] 29 #  - stored in a member namedm_testCondnsArray 30 #  - a function to set it named addTestCondition.31 #  - a parameter description for the GUI to use as a tool tip 32 #The [implement] clause causes the translation phase of to 33 # generatea default implementation of this function. 34 # 35 TestConditionTestConditionParam 36 { 37 Cardinality = 1−n; 38 Attribute =m_testCondnsArray; 39 SetFunction = addTestCondition [Implement]; 40Description = “The TestCondition parameter for a FunctionalTest”; 41 }42 } 43 # 44 # The section below is part of the Pre-Header which is anescape 45 # into C++ code. This will be referred to as a “templateblock.” 46 # 47 # Everything in this section will be reproduced verbatimin the 48 # generated header file, except for “$Class”, “$Inc”, 49 #“$ParamAryTypes”, “$ParamAttrs”, “$ParamFns” and “$ParamImpls”. 50 # 51# Note that no comments beginning with the ‘#’ character are supported52 # within the following section. 53 # 54 CPlusPlusBegin 55 $Inc 56namespace 57 { 58 class $Class 59 { 60 // Array types for parametersstorage: 61 $ParamAryTypes 62 public: 63 virtual void preExec( ); 64virtual void exec( ); 65 virtual void postExec( ); 66 $ParamFns 67 ...68 private: 69 double m_someVar; 70 $ParamAttrs 71 ... 72 }; 73 ... 74$ParamImpls 75 } // End namespace 76 CPlusPlusEnd

[0577] As the compiler processes a pre-header file, it builds up thevalues of the compiler variables such as $Inc, $Class, $ParamAryTypesand others. This enables it to then create the following C++ header bygenerating the C++ code above verbatim, and expanding in the values ofthe compiler variables $Inc, $Class, etc. at the indicated places. ForFunctionalTest.ph, it creates the following C++ header fileFunctionalTest.h for the FunctionalTest class.  1 #line 7“./FunctionalTest.ph”  2 #include <ITest.h>  3 #line 5“./FunctionalTest.ph”  4 #include <Test1.h>  5 #line 6“./FunctionalTest.ph”  6 #include <Test2.h>  7 #line 55“./FunctionalTest.ph”  8 #include <vector>  9 #line 55“./FunctionalTest.ph” 10 #include <Levels.h> 11 #line 55“./FunctionaITest.ph” 12 #include <TestCondnGrp.h> 13 ... 14 #line 56“./FunctionalTest.ph” 15 namespace 16 { 17 #line 7 “./FunctionalTest.ph”18 class FunctionalTest : public ITest, 19 #line 8 “./FunctionalTest.ph”20 public Test 1, 21 #line 8 “./FunctionaITest.ph” 22 public Test2 23#line 59 “./FunctionaITest.ph” 24 { 25 // Array types for parametersstorage: 26 #line 61 “./FunctionalTest.ph” 27 public: 28 #line 37“./FunctionaITest.ph” 29 typedef std::vector<Tester::TestCondition *>TestConditionPtrsAry_t; 30 #line 62 “./FunctionalTest.ph” 31 public: 32virtual void preExec( ); 33 virtual void exec( ); 34 virtual voidpostExec( ); 35 public: 36 #line 7 “./FunctionalTest.ph” 37 voidsetName(OFCString &name); # Automatic for all tests 38 #line 22“./FunctionalTest.ph” 39 void setPatternTree(PatternTree *); 40 #line 23“./FunctionalTest.ph” 41 String getPListParamDescription( ) const; 42#line 39 “./FunctionalTest.ph” 43 void addTestCondition(TestCondition*); 44 #line 40 “./FunctionalTest.ph” 45 voidgetTestConditionParamDescriptionO const; 46 #line 67“./FunctionalTest.ph” 47 ... 48 private: 49 double m_someVar; 50 #line70 “./FunctionalTest.ph” 51 private: 52 #line 7 “./FunctionalTest.ph” 53OFCString m_name; # Automatic for all tests 54 #line 21“./FunctionalTest.ph” 55 Tester::PatternTree *m_pPatList; 56 #line 38“./FunctionalTest.ph” 57 TestConditionPtrsAry_t m_testCondnsArray; 58#line 71 “./FunctionalTest.ph” 59 ... 60 }; 61 ... 62 #line 7“./FunctionalTest.ph” 63 inline void 64 #line 7 “./FunctionalTest.ph” 65FunctionalTest::setName(OFCString &name) 66 #line 74 “./FunctionalTesth”67 { 68 m_name = name; 69 return; 70 } 71 #line 39 “./FunctionalTest.ph”72 inline void 73 #line 39 “./FunctionalTest.ph” 74FunctionalTest::addTestCondition(TestCondition *arg) 75 #line 74“./FunctionalTest.ph” 76 { 77 m_testCondnsArray.push_back(arg); 78return; 79 } 80 #line 23 “./FunctionalTest.ph” 81 inline void 82Tester::String FunctionalTest::getPListParamDescription( ) 83 { 84return “The PList parameter for a FunctionalTest”; 85 } 86 #line 40“./FunctionalTest.ph” 87 inline void 88 Tester::StringFunctionalTest::getTestConditionParamDescription( ) 89 { 90 return “TheTestCondition parameter for a FunctionalTest”; 91 } 92 #line 75“./FunctionalTest.ph” 93 } // End namespace

[0578] As described earlier, this pre-header enables the compiler tocheck the validity of a FunctionalTest declaration, to generate code forit, and to generate a C++ header that would be needed by it.

[0579] As an example, consider the FunctionalTest declaration givenearlier, reproduced below for convenience: Test FunctionalTest FuncTest1{ PListParam = patList1; # Previously defined pattern listTestConditionParam = TC1; TestConditionParam = TC2; }

[0580] The C++ header that would be generated for this by the compileris given above. The compiler would generate the following code for theabove FunctionalTest construct:

[0581] FunctionalTest FuncTest1;

[0582] FuncTest1.setName(“FuncTest1”);

[0583] FuncTest1.setPatternTree(&patList1);

[0584] FuncTest1.addTestCondition(&TC1);

[0585] FuncTest1.addTestCondition(&TC2);

[0586] Notice also the name that is generated for the Descriptionfunction. Each parameter named Xxx is associated with a member function:

[0587] Status getXxxDescription( ) const;

[0588] that returns the string with a description for the tool tip thatthe GUI can use.

[0589] Other Pre-Header Features

[0590] The pre-header supports some other user defined enumerations asan additional type. This allows the GUI to provide a drop down list ofpossible choices that could be used for setting the value of aparticular parameter. Furthermore, the pre-header provides a feature toassociate a number of parameters that can be thought of as a table. Forexample, it may be convenient to implement an array of “properties” asan associated set of an array of strings for the names, and an array ofintegers for the values. One easy way of implementing this feature is touse an array of custom types (discussed later). However, that requiresthe user to write a custom type pre-header to use. Both of thesefeatures are illustrated in the following example: #--------------------------------------------------------- # FileFooBarTest.ph # # Parameterization specification pre-header for # customtest class FoobarTest #--------------------------------------------------------- Version 1.0;Import Test1.ph; # For base class Test 1 TestClass = FoobarTest; # Thename of this test class PublicBases = Test1; # List of public baseclasses # The parameters list: Parameters { # An enumerated type EnumWishyWashy = Yes, Perhaps, Possibly, Maybe, MaybeNot, No; # Define aWishyWashy parameter. WishyWashy WW { Cardinality = 1; Attribute = m_ww;SetFunction = setWw; Description = “The WW parameter for a Foobar Test”;} # This class has an array of name-number pairs that is # interpretedin the class. ParamGroup { Cardinality = 0−n; # The Name field in thisarray is: #  - of type String #  - [represented by C++ typeTester::String] #  - stored in a member named m_NameArray #  - afunction to set it named addName. #  - a parameter description for theGUI to use as a tool tip String Name { Attribute = m_NameArray;SetFuncti n = addName; Description = “A Name with a Value”; } # TheNumber field in this array is: #  - of type Integer #  - [represented byC++ type int] #  - stored in a member named m_NumberArray #  - afunction to set it named addNumber. #  - a parameter description for theGUI to use as a tool tip Integer Number { Attribute = m_Number Array;SetFunction = addNumber, Description = “The value of the Name”; } } #The following declaration specifies that a FunctionalTest has #  - aparameter of type PList #  - [represented by C++ typeTester::PatternTree] #  - stored in a member named m_pPatList #  - afunction to set it named setPatternTree. #  - a parameter descriptionfor the GUI to use as a tool tip PList PListParam { Cardinality = 1;Attribute = m_pPatList; SetFunction = setPatternTree; Description = “ThePList parameter for a FunctionalTest”; } # # The following declarationspecifies that a FunctionalTest has #  - 1 or more parameters of typeTestCondition #  - [represented by C++ type Tester::TestCondition] #  -stored in a member named m_testCondnsArray #  - a function to set itnamed addTestCondition. # The [implement] clause causes the translationphase of to # generate a default implementation of this function. #TestCondition TestConditionParam { Cardinality = 1−n; Attribute =m_testCondnsArray; SetFunction = addTestCondition [Implement];Description = “The TestCondition parameter for a FunctionalTest”; } }CPlusPlusBegin $Inc namespace { class $Class { // Array types forparameters storage: $ParamAryTypes public: virtual void preExec();virtual void exec(); virtual void postExec(); $ParamFns // ... private:double m_someVar; $ParamAttrs // ... }; // ... $ParamImpls } // Endnamespace CPlusPlusEnd

[0591] It must be noted that a custom type name-number pairs could havebeen declared, and a single array parameter of that custom type couldhave been used to have the same effect as the above ParamGroup ofparameters. The technique presented above is a convenience that avoidsthe necessity of declaring a custom type.

[0592] C5. Custom Function Declarations

[0593] This allows the user to call custom functions when a flowtransition takes place. Custom functions are declared through pre-headeras follows: # ---------------------------------------------------------# File MyFunctions.ph # # Parameterization specification pre-header forMyFunctions # ---------------------------------------------------------Version 1.0; Functions = MyFunctions; # The name of this group offunctions # Declare the following C++ function in the # MyFunctionsnamespace to determine the minimum # of two values. # // Return theminimum of x, y # double MyRoutines::Min # (ITestPlan* pITestPlan,int&x, int& y); Integer Min(Integer x, Integer y); # Declare the followingC++ function in the # UserRoutines namespace to return the average of #an array. # // Return the average of the array # double MyRoutines::Avg# (ITestPlan* pITestPlan, double* a, const int a_size); # The C++function will be called with a and a’Length Double Avg(Double a[ ]); #Declare the following C++ function in the # UserRoutines namespace toprint the dut id # and a message # // Return the average of the array #double MyRoutines::Print # (ITestPlan* pITestPlan, String* msg, unsignedint& dutId); # The C++ function will be called with a and a’Length VoidPrint(String msg, UnsignedInteger dutId);

[0594] Typically a C++ section needs to be provided for the abovedeclarations, as the compiler will expand these declarations in astandard way. The user is of course responsible for the C++implementation of these functions. Note that all of the above functionswill presumably take an ITestPlan pointer as an implicit firstparameter. This pointer provides the function writer access to stateS inthe TestPlan. For instance, the function writer could use the ITestPlaninterface to access the current Flow, the current FlowItem in the flow,the current Result clause, values of UserVars, and other suchinformation. Certain tester defined functions are available for use inthe file Functions.ph: Version 1.2.3; # # File Functions.ph # Functions= Functions; # The name of this group of functions # Declare thefollowing C++ function in the # Functions namespace # Returns the ID ofthe current DUT being tested by the # caller. UnsignedInteger GetDUTID();

[0595] C++ for Custom Function Declarations

[0596] The C++ code that would be generated by compiler for MyFunctionsabove is to simply declare some functions in the MyFunctions namespace:namespace MyFunctions { double Min(ITestPlan* pITestPlan, int& x, int&y); double Avg(ITestPlan* pITestPlan, double* a, const int a_size); voidPrint(ITestPlan* pITestPlan, char* Msg, unsigned int dutID); }

[0597] These functions will be callable from a flow.

[0598] C6. Custom Flowables

[0599] It is also possible to create a pre-header implementing the C++IFlowable interface using the pre-header. This enables a user to definecustom flowables that can be run in a FlowItem. Shown below is apre-header for the user-defined Flowable MyFlowable: #--------------------------------------------------------- # FileMyFlowable.ph # # Parameterization specification pre-header forMyFlowable # ---------------------------------------------------------Version 1.2.4; FlowableClass = MyFlowable; # The name of this customclass # The parameters list: Parameters { # The following declarationspecifies that a MyFlowable has # - 1 optional parameter Int1 of typeInteger # - [represented by C++ type int] # - stored in a member namedm_int1Val # - a function to set it named setInt1Val. Integer Int1 {Cardinality = 0-1; Attribute = m_int1Val; SetFunction = setInt1Val; } #The following declaration specifies that a MyFlowable has # - 1mandatory parameter Int2 of type Integer # - [represented by C++ typeint] # - stored in a member named m_int2Val # - a function to set itnamed setInt2Val. Integer Int2 { Cardinality = 1; Attribute = m_int2Val;SetFunction = setInt2Val; } # The following declaration specifies that aMyFlowable has # - one or more parameters of type String # -[represented by C++ type Tester::String] # - stored in a member namedm_stringArrVal # - a function to set it named addStringVal. StringStringItem { Cardinality = 1-n; Attribute = m_stringArrVal; SetFunction= addStringVal; } # The following declaration specifies that aMyFlowable has # - A single PList parameter # - [represented by the C++type Tester::PList] # - stored in a member named m_plist # - a functionto set it named setPListParam PList PListParam { Cardinality = 1;Attribute = m_plist; SetFunction = setPListParam; } } # # The sectionbelow is part of the Pre-Header which is an escape # into C++ code. # #Everything in this section will be reproduced verbatim in the #generated header file, except for “$Class”, “$Inc”, # “$ParamAryTypes”,“$ParamAttrs”, “$ParamFns” and “$ParamImpls”. # # Note that no commentsbeginning with the ‘#’ character are supported # within the followingsection. # CPlusPlusBegin $Inc namespace { class $Class { // Array typesfor parameters storage: $ParamAryTypes public: virtual void preExec( );virtual void exec( ); virtual void postExec( ); $ParamFns // ...private: double m_someVar; $ParamAttrs // ... }; // ... $ParamImpls } //End namespace CPlusPlusEnd

[0600] There are several classes implementing the IFlowable interface.These include:

[0601] 1. Flows for program loading which will check whether a test plancan be executed within the current tester configuration.

[0602] 2. Flows for pattern loading which will load specific patternsand pattern lists.

[0603] 3. Flows for initialization which will put hardware and softwarein a known state, load global variables, and do other initialization andvalidation functions.

[0604] 4. Other generally useful test flows.

[0605] C7. Custom Types

[0606] The discussion on Test class parameterization earlier onlyallowed for test class parameters to be of known types, viz., elementarytypes and tester-defined types such as PLists, and TestConditions. Foruser flexibility, it is important to provide type extensibility, wherebytypes (that are unknown a-priori to the compiler) can be created andused. Custom types (CTs) will be defined in the Custom Types. These canbe used to define types corresponding to C-language structs (alsoreferred to as Plain Old Data types, or PODs, which are quite differentfrom their namesakes in C++) as well as for types corresponding toC-language typedefs for function signatures. A separate file with usertypes will have the extension .ctyp. Here is an example of a user typesdeclaration in accordance with the preferred embodiment of the presentinvention: #--------------------------------------------------------- #File MyCustomTypes.ctyp#--------------------------------------------------------- Version1.0.0; CustomTypes { # A structured Plain-Old-Data type Pod Foo { StringS1; # String is a standard type Integer I1; # ... and so is IntegerString S2; } # Another structured type using Foo Pod Bar { Foo Foo1;String S1; Foo Foo2; } # # A pointer to a function. # Return type:Integer # Parameters: Integer, Integer # Routine BinaryOp(Integer,Integer) Returns Integer; # # Another pointer to a function. # Returntype: Void # Parameter: Integer # Routine UnaryOp(Integer) Returns Void;# # A pointer to a function that takes # no parameters and does notreturn a value. # Routine NullaryOp( ) Returns Void; }

[0607] C++ for Custom Types

[0608] The CustomTypes declaration presented above will be translated bythe compiler into the following C++ code: namespace CustomTypes { structFoo { Tester::String S1; int I1; Tester::String S2 }; struct Bar { FooFoo1 Tester::String S1; Foo Foo2; }; typedef int (*BinaryOp) (int&,int&); typedef void (*UnaryOp)(int); typedef void (*NullaryOp)( ); }

[0609] Objects of these types can be passed to Test classes asparameters, as shown next.

[0610] Using Custom Types as Test Class Parameters

[0611] Consider the case where the user has an extension to a test,which needs to be initialized with—in addition to pattern lists and testconditions—other class objects, as well as arbitrary (i.e.,user-defined) objects that are defined within a file containing CustomTypes (i.e., a .ctyp file). For example, suppose the user wants to usethe CTs defined in the file MyTestCTs.ctyp: # File MyTesetCTs.ctypVersion 1.0; CustomTypes { Pod Foo { String name; PList patternList; }Pod Bar { Foo someFoo; Double dVal; } Routine BinaryOp(Integer, Integer)return Integer; }

[0612] All that the user needs to do to use the above types is importthe above file in his test class pre-header. Since the compilerinterprets CTs that are so defined, the definitions for Foo and Bar aretherefore available to it when it is processing the test classpre-header. Moreover, the compiler defines two C-language structs,struct Foo and Struct Bar, corresponding respectively to the types Fooand Bar above, the definitions for which are placed in the filemyTestCTs.h. The Import statement for myTestCTs.ctt causes the filemyTestCTs.h to be #include-d in the generated test class C++ header. Thefollowing example illustrates this process. First, consider thedeclaration for the test in the test plan (the declarations for patternlists and test conditions have been omitted for clarity): ... ImportMyFunctions.ph; Import MyCustomTypes.ctyp; ... # The CustomVars blockdefines variables of the Custom # types defined earlier. CustomVars {... Bar bar1 = { { ”This is a Foo”, somePatList }, # someFoo 3.14159 #dVal } # # A function object that is a binary operator. # The name onthe right hand side of the assignment # is a routine declared inMyFunctions, for which, # of course, the user has to provide animplementation. # BinaryOp bop1 = MyFunctions.Min; } ... TestMyFancyTest MyTest1 { ... BarParam = bar1; BinaryOpParam = bop1; } ...

[0613] In the above example, a CustomVars block is included in a testplan. A separate file with customization variables will have theextension .cvar. The user would write a pre-header for MyFancyTest thatsupports the above parameterization as follows (the parameterizationdeclarations for pattern lists and test conditions have been omitted forclarity): # --------------------------------------------------------- #File MyFancyTest.ph # # Parameterization specification pre-header forMyFancyTest # ---------------------------------------------------------Version 1.0.2; Import MyCustomTypes.ctyp; # For CTs used in MyFancyTestImport FunctionalTest.ph; # For base class FunctionalTest TestClass =MyFancyTest; # The name of this test class PublicBases = FunctionalTest;# List of public base classes # The parameters list: Parameters { # Thefollowing declaration specifies that a MyFancyTest has # - an optionalarray of parameters of custom type Bar # - [represented by C++ typeCustomTypes::Bar] # - stored in a member named m_barsArray # - afunction to set it named addBarParam. # An implementation will begenerated for addBarParam. Bar BarParam { Cardinality = 0-n; Attribute =m_barsArray; SetFunction = addBarParam [Implement]; } # The followingdeclaration specifies that a MyFancyTest has # - an optional parameterof custom type BinaryOp # - [represented by C++ typeCustomTypes::BinaryOp] # - stored in a member named m_binaryOp # - afunction to set it named setBinaryOpParam. # An implementation will begenerated for setBinaryOpParam. BinaryOp BinaryOpParam { Cardinality =0-1; Attribute = m_binaryOp; SetFuncti n = setBinaryOpParam [Implement];} } CPlusPlusBegin $Inc namespace { class $Class { $ParamAryTypespublic: virtual void preExec( ); virtual void exec( ); virtual voidpostExec( ); $ParamFns // ... private: double m_someVar; $ParamAttrs //... }; // ... $ParamImpls } // End namespace CPlusPlusEnd

[0614] C++ for Custom Test Classes using Custom Types

[0615] Finally, once the compiler has processed this pre-header file, itwill create the following C++ header file for the MyFancyTest class,MyFancyTest.h: #include <MyCustomTypes.h> #include <ITest.h> #include<FunctionalTest.h> ... namespace { class MyFancyTest : public ITest,public FunctionalTest { public: typedef std::vector<CustomTypes::Bar *>BarAry_t; public: virtual void preExec( ); virtual void exec( ); virtualvoid postExec( ); public: void setName(OFCString &name); # Automatic forall tests void setPatternTree(PatternTree *); voidaddTestCondition(TestCondition *); void addBarParam(CustomTypes::Bar *);void setBinaryOpParam(CustomTypes::BinaryOp *); ... private: doublem_someVar; private: OFCString m_name; # Automatic for all testsPatternTree *m_pPatList; TestConditionPtrsAry_t m_testCondnsArray;BarAry_t m_barsArray; BinaryOp *m_binaryOp; ... }; // End classMyFancyTest ... inline void MyFancyTest::addBarParam(CustomTypes::Bar*arg) { m_barsArray.push_back(arg); return; } inline voidMyFancyTest::setBinaryOpParam(CustomTypes::BinaryOp *arg) { m_binaryOp =arg; return; } } // End namespace

[0616] C8. Parameterization

[0617] As seen above, a pre-header for a Test class, custom Flowableclass, or custom function definitions offers limited introspection intothe class/functions through a parameterization specification section.The compiler uses this section to generate the parameterizationinterface for the class/function (and generate the class/function headeritself). For Test classes and Flowable classes, it also uses thissection to subsequently generate the calls in the Test Plan code toinitialize an instance of that class. The following points concerningpre-headers and corresponding declaration should be noted:

[0618] 1. Every Test or custom Flowable class definition is preferablyspecified in a pre-header. The Parameters block in the pre-header ispreferably the only place where the parameters list for such a class canbe specified. (Thus, as a corollary, the “standard” parameters for aTest, such as pattern list and test condition specifications, also needto be included in the pre-header's Parameters block; this allows allparameters, standard and CTs, to be treated uniformly.)

[0619] 2. All parameters defined as non-optional (i.e., with a non-zerocardinality) in the pre-header for a Test or Flowable class should beinitialized in the Test block or Flowable block declaration for aninstance of that class.

[0620] 3. The objects used for initialization of parameters in theTest/Flowable block should have been defined previously.

[0621] 4. The replacement indicators $Class, $Inc, $ParamAryTypes,$ParamFns, $ParamAttrs and $ParamImpls must appear at the exactlocations within the user code section of the pre-header that the userintends the corresponding generated code to be inserted at in thegenerated class header file. These should appear exactly once, sincespecific code is generated for each.

[0622] 5. The name of a parameter specification in the Parameters blockof the pre-header (such as PListParam, TestConditionParam or BarParam inthe examples above) is the name of the parameter to be used in thedeclaration of an instance of that class.

[0623] 6. The following are the semantics of the descriptors used in aparameter specification:

[0624] a. Cardinality: This indicates the number of parameters of thistype that will be supported. The following are the possible values inone embodiment:

[0625] i. 1: This parameter is mandatory, and should be specifiedexactly once. This parameter will be maintained as a pointer to anobject of the type of the parameter.

[0626] ii 0-1: This parameter is optional; if specified, it must bespecified only once. This parameter will be maintained as a pointer toan object of the type of the parameter.

[0627] iii 1-n: This parameter is mandatory. Moreover, multiple valuescan be specified for this. The values will be stored in the order ofspecification.

[0628] iv 0-n: This parameter is optional. Multiple values can bespecified for this. The values will be stored in the order ofspecification.

[0629] Note that for ( ) and ( ) above, all specified values will bestored in an STL vector< >, templated on a pointer to the type of theparameter. The type of this vector will be defined and inserted at thepoint indicated by $ParamAryTypes. The access level for these typedefinitions is always public.

[0630] b. Attribute: The name of the C++ variable to use as the storefor parameter value(s) of this type. The name will be reproducedverbatim, as a private data member of the C++ class, and must conform tothe requirements for a C++ identifier. Note that the type of thisattribute is:

[0631] i. A pointer to the type of the parameter, if only single valuesare permitted;

[0632] ii. An STL vector< >, templated on a pointer to the type of theparameter, if multiple values are permitted (see ( ) above).

[0633] Note that the attributes hold references to objects created andpopulated by the Test Plan, and do not own these objects. The lifetimeof the objects are always managed by the Test Plan itself.

[0634] c. SetFunction: The name of the function to use for setting avalue for this parameter. The following points should be noted:

[0635] i. The name will be reproduced verbatim, and hence, must conformto C++ language requirements.

[0636] ii. The access level of the function is always public.

[0637] iii. The return type is always void.

[0638] iv. The function always takes only a single argument, of typepointer-to-parameter-type.

[0639] Note that a value is always set singly; i.e., for parameters thatallow specification of multiple values, the generated code in the TestPlan will call this function repeatedly, once for every value specified,each of which will be added to an STL vector (as described above).

[0640] The optional keyword “[implement]” following the function nameindicates that a trivial implementation for this function will be madeavailable as an inline method in the class header (inserted at the pointindicated by $ParamImpls). Otherwise, the user is responsible forproviding an implementation of the function.

[0641] d. Description: A string literal that is a tooltip which will beused by a GUI tool to provide help during runtime modification of thisparameter. The C++ member function generated in the custom class for aparameter named Xxx will be

[0642] String getXxxDescription ( ) const;

[0643] The function will return the specified string.

[0644] Test Plan Example with Customization

[0645] Shown below is the test plan example embellished with somecustomization: #--------------------------------------------------------- # FileMyCustomizedTestPlan.tpl #--------------------------------------------------------- Version 0.1; ## Imports as before ... # The following import is implicit, but can beexplicitly # provided. Import FunctionalTest.ph; # Import forMyFlowables, MyFunctions and Functions Import MyFlowables.ph; ImportMyFunctions.ph; Import Functions.ph;#--------------------------------------------------------- # Start ofthe test plan #---------------------------------------------------------TestPlan Sample; # This block defines Pattern Lists file-qualified namesand # Pattern List variables that are used in Test declarations. # Thefile-qualified names refer to pattern lists in the named # files. Thevariables refer to String variables which will # hold the pattern listnames at run time. User defined Flowable # objects could set the valuesof these variables through an # API. PListDefs { # File qualifiedpattern list names pl1A.plist:pat1Alist, pl2A.plist:pat2AList, # Patternlist variables plistXxx, plistYyy, plistZzz } # SocketDef, UserVarsdeclaration as before ... # Declarations of TestConditions TC1Min,TC1Typ, TC1Max, # TC2Min, TC2Typ, TC2Max as before ... # # Declare aFunctionalTest. “FunctionalTest” refers to a C++ # test class that runsthe test, and returns a 0, 1 or 2 as # a Result. The Test ConditionGroup TCG1 is selected with # the “min” selector by referring to theTC1Min TestCondition. # # Note that compiler can compile this because ofthe imported # FunctionalTest.ph file. # Test FunctionalTestMyFunctionalTest1Min { PListParam = pat1AList; TestConditionParam =TC1Min; } # # Additional FunctionalTest declarations for the following,as before # MyFunctionalTest1Typ # MyFunctionalTest1Max #MyFunctionalTest2Min # MyFunctionalTest2Typ # MyFunctionalTest2Max # #Here is a declaration of MyFlowable. It uses a PatternList variable #plistXxx which is initialized by the flowable prior to use here. # #Compiler can compile this because of the imported MyFlowables.ph file:Flowable MyFlowable MyFlowable1 { Int1 = 10; Int2 = 20; StringItem =“Hello World”; PListParam = plistXxx; } # Counters for PassCount andFailCount as before ... # Flows as before. Flows FlowTest1 and FlowTest2are # unchanged from the previous example. Flow FlowTest1 { # ... } FlowFlowTest2 { # ... } # # Now FlowMain, a main flow, can be presented. It# implements a finite state machine that calls FlowTest1 # and FlowTest2as below: # ------------------------------------ # Result 0 Result 1 #------------------------------------ # FlowMain_1 FlowMain_2 return 1 #FlowMain_2 FlowMain_3 return 1 # FlowMain_3 FlowMain_4 return 1 #FlowMain_4 FlowMain_5 return 1 # FlowMain_5 return 0 return 1 # # Wherethe IFlowables run by each FlowItem are: #------------------------------------------ # FlowItem IFlowable that isrun # ------------------------------------------ # FlowMain_1MyFlowable1 # FlowMain_2 DatalogStartFlow # FlowMain_3 FlowTest1 #FlowMain_4 FlowTest2 # FlowMain_5 DatalogStopFlow # Flow FlowMain { # #The first declared flow is the initial flow to be # executed. It goes toFlowMain_InitializationFlow # on success, and returns 1 on failure. #FlowItem FlowMain_1 MyFlowable1 { Result 0 { Property PassFail = “Pass”;IncrementCounters PassCount; # A user function call MyFunctions.Print(“Passed MyFlowable1”, Functions.GetDUTID( )); GoToFlowMain_2; } Result1 { Property PassFail = “Fail”; IncrementCounters FailCount; # A userfunction call MyFunctions.Print(“Failed MyFlowable1”,Functions.GetDUTID( )); SetBin SoftBins.“3GHzLeakage”; Return 1; } } # #Goes to FlowMain_3 on success # and returns 1 on failure. # FlowItemFlowMain_2 DatalogStartFlow { Result 0 { Property PassFail = “Pass”;IncrementCounters PassCount; # A user function callMyFunctions.Print(“Passed DatalogStartFlow”, Functions.GetDUTID( ));GoToFlowMain_3; } Result 1 { Property PassFail = “Fail”;IncrementCounters FailCount; MyFunctions.Print(“FailedDatalogStartFlow”,Functions.GetDUTID( )); Return 1; } } # This FlowItem calls thepreviously defined FlowTest1 FlowItem FlowMain_3 FlowTest1 { Result 0 {Property PassFail = “Pass”; IncrementCounters PassCount; # A userfunction call MyFunctions.Print(“Passed FlowTest1”, Functions.GetDUTID()); GoTo FlowMain_4; } Result 1 { Property PassFail = “Fail”;IncrementCounters FailCount; # A user function callMyFunctions.Print(“Failed FlowTest1”, Functions.GetDUTID( )); SetBinSoftBins.“3GHzCacheFail”; Return 1; } } # This FlowItem calls thepreviously defined FlowTest2 FlowItem FlowMain_4 FlowTest2 { Result 0 {Property PassFail = “Pass”; IncrementCounters PassCount; # A userfunction call MyFunctions.Print(“PassedFlowTest2”, Functions.GetDUTID()); GoTo FlowMain_5; } Result 1 { # FlowTest1 passed, but FlowTest2failed Property PassFail = “Fail”; IncrementCounters FailCount; # A userfunction call MyFunctions.Print(“Failed FlowTest2”, Functions.GetDUTID()); SetBin SoftBins.“3GHzSBFTFail”; Return 1; } } FlowItem FlowMain_5DatalogStopFlow { Result 0 { # All Passed! Property PassFail = “Pass”;IncrementCounters PassCount; # A user function callMyFunctions.Print(“Passed all!”, Functions.GetDUTID( )); SetBinSoftBins.“3GHzAllPass”; Return 0; } Result 1 { # FlowTest1 and FlowTest2passed, # but DatalogStopFlow failed Property PassFail = “Fail”;IncrementCounters FailCount; # A user function callMyFunctions.Print(“Failed DatalogStopFlow”, Functions.GetDUTID( ));Return 1; } } }

[0646] The following points need to be noted about the above code:

[0647] 1. The PListDefs section here has some PList names and also somePList variables. The PList names are names that can directly be used intests. The PList variables are variables which can be used in tests, andwhose value is bound at runtime to actual PLists by code in a customizedFlowable.

[0648] 2. The PListDefs section is optional. If not present, itscontents will be inferred by compiler from the various Testdeclarations. If present, it must declare all of the used PListparameters of Tests, though it may declare more.

[0649] 3. A runtime API will be available to assign values to PListvariables. The TestPlan class will have a function:

[0650] Status SetPListVariable(const Tester::String& varName, constTester::String& fileQualifiedPListName);

[0651] The Flowable will be able to use the above function to bind aPListVariable to a particular PList.

[0652] 4. User functions and functions can be called in FlowItems justprior to a transition, which is either a transfer of control to anotherFlowItem, or a return.

[0653] C++ for User Function Calls

[0654] With the exception of invoking custom function calls in flows,C++ code that would be generated by the compiler has been shown for thevarious customization techniques presented earlier. User function callsin a FlowItem are preferably handled by an IUserCalls member of eachFlow. Each Flow preferably has a member of the interface IUserCallswhich exports a single virtual member function, as shown below: classIUserCalls { public: virtual void exec(const String& flowItemName,unsigned int result) = 0; };

[0655] When a Flow with user function calls is encountered, the Flowgets populated with an instance of a class that implements the aboveinterface. For example, in FlowMain in the example in the flow will bepopulated with an instance of the following class: classFlowMain_UserCalls : public IUserCalls { public: virtual void exec(constString& flowItemName, unsigned int result) { if (flowItemName = =“FlowMain_1”) { // ... } else if (flowItemName = = “FlowMain_2”) { //... } else if (flowItemName = = “FlowMain_3”) { switch (result) { case0: MyFunctions::Print(“PassedFlowTest1”, Functions::GetDUTID( ));return; case 1: MyFunctions::Print(“FailedFlowTest1”,Functions::GetDUTID( )); return; default: return; } } else if(flowItemName = = “FlowMain_4”) { // ... } else if (flowItemName = =“FlowMain_5”) { // ... } } };

[0656] The Flowltem::execute( ) operation knows the name of the flowitem. Before it returns with the pointer to the next flow, it will callIUserCalls::exec( ) for the enclosing flow, passing its own flow itemname, and the value of the current result. This will cause the abovecode to be executed, invoking the needed user defined functions.

[0657] C9. Test Program Compilation

[0658] As explained above, the Test Plan description file specifies theobjects used in a test plan and their relationships to one another. Inone embodiment, this file is translated to the C++ code that will beexecuted on the Site Controller in the form of an implementation of astandard interface ITestPlan. This code can be packaged into a Windowsdynamic link library (DLL) which can be loaded onto the Site Controller.The Test Program DLL is generated to have standard known entry pointsthat the Site Controller software can use to generate and return theTestPlan object it contains.

[0659] Construction from a Test Plan Description

[0660] The process of conversion from a test plan description to animplementation of ITestPlan is accomplished by the test program compiler400. This process occurs in two phases: translation and compilation.

[0661] In the translation phase 402, the compiler 400 processes a testplan file (and the various other files it imports), as well as thepre-headers for all the test types used in the test plan. In this phase,it creates the C++ code for the Test Plan object and the C++ headers forthe test types encountered, along with all other supporting files, suchas MSVC++(Microsoft Visual C++) workspace and project files, DLL“boilerplate” code, etc. The compiler 400 inserts file and linedirectives into the generated code to ensure that compile-time errormessages refer back to the appropriate location in the description fileinstead of pointing into the generated code.

[0662] In the compilation phase, which occurs after the compiler hascreated the necessary files, a standard compiler 404, such as an MSVC++compiler, is invoked to compile the files and link them into a DLL.

[0663] The compiler takes, as input, a valid test plan file (and allrelated files), and generates, as necessary, a TestPlan file and allother files represented by “Import” directives in the test plan file. Inaddition, it generates a MSVC++ “Solution” to build the Test Plan DLL.For example, if the main file (MyTestPlan.tpl) included Timing1.tim toincorporate timing information, then the compiler would create (amongothers) the following files:

[0664] MyTestPlan.h

[0665] MyTestPlan.cpp

[0666] Timing1.cpp

[0667] MyTestPlan.sln (MSVC++ “Solution” file)

[0668] MyTestPlan.vcproj (MSVC++ “Project” file)

[0669] After all files are created (or updated), the compiler invokesthe MSVC++ application, specifying the “Solution” it created, and buildsthe DLL. Any errors and/or warnings would be shown to the user.

[0670] If, after building the Test Plan, the user made a change toTiming1.tim, the user would then invoke the compiler, passing itMyTestPlan.tpl. The compiler would recognize (by timestamp information)that the main test plan file is unchanged, so that MyTestPlan.h/.cppwould not be recreated. However, while processing the main test planfile, it would see that the Timing.tim file has changed. Therefore, itwould recreate the Timing1.cpp file, and invoke the MSVC++ applicationto rebuild the DLL. This avoids recompiling MyTestPlan.cpp, and onlycompiles Timing1.cpp and re-links the DLL. This approach will beespecially useful in cutting down re-compile and re-link times for largetest plans that take a significant amount of time to compile.

[0671] D. Running the Test Program

[0672] The Site Controller software loads the Test Program DLL into itsprocess space and calls a “factory” function within the DLL to create aninstance of the Test Plan object. Once the Test Plan object has beencreated, the Site Controller software can then execute the test plan orinteract with it in any other way necessary.

[0673] Non-Interactive Builds

[0674] To most C++ software developers in the Windows environmentbuilding an application (or a DLL, or Library, etc) means bringing up adevelopment environment (MS Visual C++, Borland C++, or similar),editing code, and (often) pressing a button to build the product.

[0675] The test environment of an embodiment of the invention will havea similar set of activities. Test Plan developers will need to edit codeand build their Test Plans. However, tester will not require the TestPlan developer to bring up a C++ development environment in order toproduce the resulting Test Plan DLL.

[0676] In order to accomplish this the present invention employs theconcept of a non-interactive build. A non-interactive build is definedas a build that uses MS Visual C++ in a non-interactive mode. Note thatthis still allows other tools to be used interactively to manage such abuild. The only implication is that Visual C++ is usednon-interactively.

[0677] Assumed Environment

[0678] Certain assumptions are made about the user's environment. Theassumptions are:

[0679] 1. The Test Plan developer will be developing his Test Planaccording to above methods and rules.

[0680] 2. The Test Plan developer may not have a expert level knowledgeof C++.

[0681] 3. The Test Plan developer will have access to command-line toolsor GUI tools to convert file(s) to a Test Plan DLL.

[0682] Building Applications Without Buttons

[0683] Working with MS Visual Studio non-interactively requires one oftwo approaches. The first (and simplest) is to use the command-lineinterface. The second (and more flexible) is to use the Automationinterface. This section describes both approaches.

[0684] Creating the Project

[0685] In order to use Visual Studio non-interactively one should startwith a working Solution which contains one or more valid Projects.Unfortunately, this is the one task that cannot be accomplished fromeither a command-line or Automation approach. Neither method provides amechanism for project creation. However, projects and solutions forVisual Studio can be created from a template. Therefore, given a projectname and a template to start from we can create a solution/project forVisual Studio.

[0686] Populating the Project

[0687] Adding new files to the produced project uses the Visual StudioAutomation model since the command-line does not support this. Weprovides two Visual Studio macros to add new and existing files to aproject. Similar code could be used by an external script using anActiveScript Engine (such as VBScript, JScript, ActivePerl,ActivePython, etc) to perform the same tasks. Therefore, our codegeneration tools could create new files and, using the Automation Model,add them to the existing Visual Studio project. After the files arecreated they can be updated as necessary by the tools.

[0688] Building the Project

[0689] Once we have a solution and project in place there are severaloptions to using Visual Studio non-interactively to build the Test Plan.The simplest option is to invoke it from the command-line. Such acommand-line would look like:

[0690] devenv solutionFile/build solutionCfg

[0691] where solutionFile is a Visual Studio solution file andsolutionCfg is a specific configuration applicable to the projectswithin the solution. Another solution is to use the Visual Studio ObjectModel for Automation. This allows a finer grain of control over thebuild and configuration process. As mentioned above, it contains alisting of a Perl script to build a project from the command line. Thisprogram reads a configuration file which specifies projects andconfigurations to build (as well as other information about theprojects) and builds them all using the Automation Model. Look at theuses of the $msdev object in this script for examples of how to useAutomation objects in a script.

[0692] Debugger Support

[0693] In order for developers of Test classes to verify and debug theirwork, they need access to a debugger that allows them to break into theSite Controller and step through their code. Since the code generated bythe compiler is C++ which is compiled by MSVC++, we use the MSVC++debugger to debug Test class implementations. Note that this feature ismeant only for Test class developers or others who work directly in C++.Other mechanisms will be provided to test engineers who wish to debug orstep through the operation of a Test Program without referring directlyto the generated C++ code.

[0694] System Software Environment

[0695] This section describes the general software environment for theTester: the locations for the files required by user test plans,mechanisms for specifying alternate locations for such files, and themethods for specifying the locations of the test plans and modulecontrol software.

[0696] Environment Required by Test Plans

[0697] System standard locations, as well as the runtime configurationof the search paths for

[0698] 1. pattern lists,

[0699] 2. patterns,

[0700] 3. timing data, and

[0701] 4. test class DLLs

[0702] required by a test plan, may be configured by “environment”variables, as specified by environment configuration files. These aretext files, with a simple syntax such as:

[0703] Tester_PATOBJ_PATH=“patterns\data;D:\projects\SC23\patterns\data”

[0704] The advantage of having such “environments” defined in text filesinstead of through native OS-supported environment variables is that theimplementation is then not limited by the common restrictions thatOS-supported environment variables have, such as maximum string lengths,etc. The following “environment” (setup) variables will be used for theentities listed above:

[0705] Pattern lists: Tester_PATLIST_PATH.

[0706] Pattern object files: Tester_PATOBJ_PATH.

[0707] Pattern source files: Tester_PATSRC_PATH (this is optional;please see).

[0708] Timing data files: Tester_TIMING_PATH.

[0709] Test class DLLs: Tester_TEST_CLASS_LIBPATH.

[0710] In order to support special cases, while maintaining usefuldefault behavior, we provide three levels of configuration. These aredescribed in increasing order of precedence:

[0711] First, a system environment setup file,$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env, will specify the defaultvalues of “environment” variables. If no other configuration mechanismis available, this file will be required. In general, it will beavailable for all test plans run on the system. This file is created bythe Installation and Configuration Management (ICM) system duringinstallation, with input from the installer to assign the default valuesfor the three variables mentioned above. (Note that besides the systemdefaults for the above three variables, this file will also contain thesystem defaults for certain other tester “environment” variables, asdescribed in the following sub-section.)

[0712] Second, an environment setup file may be specified by the user asa runtime argument to the test plan. The variables in this runtimeconfiguration will take precedence over default definitions.

[0713] Finally, a test plan may use a special block to specify theenvironment variables to be used in its execution. Variables defined inthe test plan will take precedence over those in the default system fileor the user-defined file.

[0714] In general, all necessary variables should be defined through oneof the mechanisms described above. If a variable is not defined, aruntime error will occur.

[0715] Other Environment Setups

[0716] Besides the “environment” variables that are required by usertest plans, the following two “environment” variables are required bythe test environment:

[0717] 1. Tester_TEST_PLAN_LIBPATH: This specifies the search path thatthe System Controller will use for finding a user test plan DLL thatshould be loaded. Note that the same search path will also be used forfinding user pin description and socket files. The default value forthis variable, specified during installation time to the ICM, is storedby the ICM in the file $Tester_INSTALLATION_ROOT\cfg\setups\Setup.env.

[0718] 2. Tester_MODULE_LIBPATH: This specifies the search path that thesystem will use to load vendor-provided hardware module control softwareDLLs. This information, extracted from the Configuration ManagementDatabase (CMD), is also stored in the file$Tester_INSTALLATION_ROOT\cfg\setups\Setup.env by the ICM.

[0719] Note that while a user can override the value given in theSetup.env file for the Tester_TEST_PLAN_LIBPATH variable, the valuegiven in the Setup.env file for the Tester_MODULE_LIBPATH should not bechanged by the user unless the user wants to explicitly change thesearch path for the vendor-provided hardware module control softwareDLLs.

[0720] Search Path Specification Semantics

[0721] The following points should be noted about the “environment”variables that specify search paths:

[0722] 1. Each should be a semicolon(”;”)-separated list of directorynames that the system will search to find a referenced file of aparticular type.

[0723] 2. After initial system lookup of the value of such an“environment” variable, any changes made by the user to its value (forexample, by editing an environment configuration file) will only beregistered by the system when the user explicitly “informs” the systemof the need to do so.

[0724] 3. Relative pathnames in the search paths will be interpreted asbeing relative to a particular setting of a related environment variable(that provides the functionality of defining a root), as paths relativeto the “current working directory” (CWD) could lead to ambiguousresults, since the notion of a CWD in a distributed environment—such asthe one in which the tester works—might not be what the user intuitivelyexpects it to be. This related environment variable, which designatesthe root that all relative pathnames in the search paths will be assumedto be relative to, is the “Tester_INSTALLATION_ROOT” variable, whichgives the location of the top-level (i.e., “root”) directory of thetester installation on a user's system.

[0725] 4. The directory entries cannot contain the characters in the set[V:*?”<>|;]; note that except for the semicolon (“;”), all the othercharacters in this set are illegal in Windows file names. The semicolon(“;”) should not be used in search path entries, since it is used todemarcate entries in the search path. Note that pathnames can haveembedded whitespaces, but all whitespaces occurring immediately beforeand after a pathname (i.e., before the first and after the lastnon-whitespace character in the pathname) will not be considered to bepart of the pathname, and will be ignored.

[0726] 5. The search path directories will be searched in the order theyare encountered in the definition. The first occurrence of a file willbe the one chosen.

[0727] E. Test Patterns

[0728] The efficient management, handling and loading of a very largeset of test pattern files is an important architectural aspect of theframework of an embodiment of the invention. The idea of hierarchicalpattern lists is regarded as being an effective tool in providingtractable conceptualization and ease of use of the system to the enduser.

[0729] The stimulus to a DUT is made available to the test systemthrough test vectors. Vectors can generally be categorized as sequential(or linear), scan or Algorithmic Pattern Generator (APG)-derived. In thesystem of an embodiment of the invention, test vectors are organized interms of patterns that are applied to the DUT at test time. A pattern isrepresented by a Pattern object in the user's test program. In thesystem, patterns are organized in pattern lists, representedprogrammatically by pattern list objects. A Pattern List objectrepresents an ordered list of patterns or other pattern lists. Theordering is implicit in the order of declaration of the list components.Note that if only a single pattern is needed, it is required to beencapsulated in a list by itself.

[0730] A pattern list object in the user's test program is associatedwith a pattern listfile on disk, which contains the actual definition ofthe pattern list. The contents of a pattern list are thus dynamicallydetermined by the contents of the associated disk file (more will besaid about this later).

[0731] The definition of a pattern list provides an explicit name forthe pattern list, and identifies an ordered list of patterns and/orother pattern lists through file name associations. It also provides forthe specification of execution options, which will be described indetail after the pattern objects have been described, since the optionscan be applied to both pattern lists and patterns. The pattern listshould follow the following rules: file-contents : version-infoglobal-pattern-list-definitions version-info : Versionversion-identifier ; global-pattern-list-definitions :global-pattern-list-definition global-pattern-list-definitionsglobal-pattern-list-definition global-pattern-list-definition :global-pattern-list-declaration { list-block }global-pattern-list-declaration : GlobalPList pattern-list-nameoptions_(opt) list-block : list-entry list-block list-entry list-entry :pattern-entry ; pattern-list-entry ; global-pattern-list-definition ;local-pattern-list-definition ; pattern-entry : Pat pattern-nameoptions_(opt) pattern-list-entry : PList pattern-list-referenceoptions_(opt) pattern-list-reference : pattern-list-qualified-namefile-name ‘:’ pattern-list-qualified-name pattern-list-qualified-name :pattern-list-name pattern-list-qualified-name ‘.’ pattern-list-namelocal-pattern-list-definition : local-pattern-list-declaration {list-block } local-pattern-list-declaration : LocalPListpattern-list-name options_(opt) options : option options option option :[ option-definition ] option-definition : option-nameoption-parameters_(opt) option-parameters : option-parameteroption-parameters ‘,’ option-parameter

[0732] The following are the descriptions of undefined non-terminalsused above:

[0733] 1. version-identifier: A sequence of one or more characters fromthe set [0-9.], where the first character must be a digit.

[0734] 2. name: A sequence of one or more characters from the set[a-zA-Z_(—)0-9], where the first character must be from the set[a-zA-Z_].

[0735] 3. pattern-list-name: A sequence of one or more characters fromthe set [a-zA-Z_(—)0-9], where the first character must be from the set[a-zA-Z_].

[0736] 4. file-name: A valid Windows file name (must be enclosed indouble quotes if any white-spaces are contained in the file name). Notethat this should be a simple file name, i.e., it should not have adirectory component. A pattern-list-reference can be either internalreferring to a pattern list in the same file, or external referring toone in another file. External references need to be qualified by afile-name.

[0737] 5. option-name: A sequence of one or more characters from the set[a-zA-Z_(—)0-9], where the first character must be from the set[a-zA-Z_].

[0738] 6. option-parameter: A sequence of one or more characters fromthe set [a-zA-Z_(—)0-9].

[0739] Pattern list files support comments, which are meant to beignored by a pattern list file parser. Comments start with the ‘#’character, and extend to the end of the line.

[0740] E1. Rules for Pattern List

[0741] The static or compile-time rules for pattern lists govern thedeclaration and resolution of names. Names in the pattern list languageare declared by global-pattern-list-definitions andlocal-pattern-list-definitions. They are referenced bypattern-list-references. Below are some rules governing thesedeclarations and references.

[0742] 1. A global-pattern-list-definition or alocal-pattern-list-definition declares the name of a pattern list. Apattern-list-reference references the name of a declared pattern list.The names of global pattern lists are globally known. The names of localpattern lists are known only in the list-block in which they aredeclared. They can be referred to without qualification directly in thatlist block. In a more deeply nested declaration, a local pattern listwill need to be referred to by a qualified name.

[0743] 2. Local pattern list names are known within the scope of anenclosing pattern list, and global pattern list names known within thescope of the system. For example: GlobalPList G1 { LocalPList L1 {LocalPList L2 { ... } GlobalPList G2 { ... } PList L2; # OK. Name L2 isknown in this scope PList G2 # OK. Name G2 is global } PList L2; #Error. Name L2 is not known here. PList L1.L2; # OK. Name L1 is knownhere. L2 is known by # qualification. PList G1.L1.L2; # OK.Qualification by G1 is not needed but # is allowed. PList G2; # OK. NameG2 is global }

[0744] 3. Global pattern lists may be defined at an outermost level in apattern list file, or may be defined as nested within an enclosingpattern list. The nesting is merely a convenience, however. They areconceptually defined as global pattern lists at the outermost level inthe file. A nested global pattern list is semantically equivalent to anoutermost (non-nested) global pattern list of the same name. So forexample: GlobalPListG1 { GlobalPList G2 ... } is semantically equivalentto: GlobalPList G1 { PList G2; # References G2 } GlobalPList G2 ...

[0745] 4. All global pattern lists are uniquely named. GlobalPList G1 {# Note that this is as if declared at the outermost level # with areference to it right here. GlobalPList G2 { ... } } # This declarationwill be an error in this or any other file, # as the name G2 is alreadytaken. GlobalPList G2 # Error. Global name G2 is taken. { ... }

[0746] 5. Local pattern lists are always have their definitions nestedwithin an enclosing pattern list which also determines the scope of thename of the local pattern list. Local pattern lists are uniquely namedwithin their enclosing pattern list. Local pattern lists aresyntactically disallowed from occurring at the outermost level in apattern list file. GlobalPList G1 { LocalPList L1 { } LocalPList L2 {LocalPList L1 # OK. No local name L1 is declared directly # in theenclosing scope defined by L2. { } PList L1 ; # OK. Refers to L1declared in L2 PList G1.L1; # OK. Refers to L1 declared in G1. } #Error. Redeclaring name L1 when the enclosing scope # defined by G1already has an L1 declared in it. LocalPListL1; { } }

[0747] 6. Each pattern list file contains the definition for one or moreglobal pattern lists. This follows directly from the syntax. Theoutermost level is a global-pattern-list-definition, and there must beat least one of them.

[0748] 7. The pattern-name is a reference to a pattern, following thePat keyword. It references a pattern that is in a pattern file whosename is obtained by concatenating a suffix pat to the pattern name. Thefile denotes a file that will be obtained along a search path definedfor patterns.

[0749] 8. A pattern-list-reference is a reference to a pattern listfollowing the PList keyword. The reference consists of an optionalfilename followed by a qualified pattern list name which is just a listof names separated by dots. So, for instance, the following could be apattern-list-reference:

[0750] PList foo.plist:G1.L1.L2.L3;

[0751] referring to a local pattern list L3 nested in L2 nested in L1nested in a global pattern list G1 that is in a file foo.plist. Theleftmost name segment in the above name is G1.

[0752] The leftmost name segment must resolve to either a global patternlist, or else to a local pattern list that is visible from the point ofreference.

[0753] Name resolution of a pattern-list-reference proceeds as follows:

[0754] 1. Each name segment resolves to a name declared in the contextof the prefix before it.

[0755] 2. If there is a file qualification, the leftmost name segmentresolves to a global pattern list declared in the named file.

[0756] 3. If there is no file qualification, the leftmost name couldresolve to a local pattern list within the enclosing scope and if thatfails then the next enclosing scope, and so on, up to an enclosingglobal scope.

[0757] 4. Limiting the searching of scopes to the closest enclosingglobal scope is needed in order to preserve the semantics of globalscopes as if they were declared at the outermost level in the patternlist file. If the nested global scope was (equivalently) textuallydeclared at the outermost level, the name resolution search wouldterminate after examining its scope.

[0758] 5. If the reference has not been resolved by the prior steps,then the leftmost name segment can be resolved to a global pattern listwithin this same file.

[0759] 6. If the reference has not been resolved by the prior steps,then the leftmost name segment can be resolved to a global pattern listnamed in the file by adding the .plist suffix to the leftmost namesegment.

[0760] 7. If the reference has not been resolved by the prior steps,then the reference is in error.

[0761] As mentioned earlier, the above rules dictate that the leftmostname segment resolves to either a local pattern list that is visiblefrom the point of reference, or else to a global pattern list.

[0762] The following example illustrates some of these ideas.GlobalPlistG1 { PList G3; # OK. Refers to a pattern list later in thisfile. PList G4; # OK. Refers to a pattern list in file “G4.plist” # OK.Refers to G1 in the file “my_plists.plist”. PList my_plists.plist:G1; #OK. Refers to a pattern list in file “my_plists.plist”. The # qualifiedname refers to a local pattern list named L2 declared # in the scope ofa local pattern list named L1 declared in the # scope of a globalpattern list named G1. PList my_plists.plist:G1.L1.L2; LocalPList L1 {LocalPList L2 { } } PList L1; # OK. Refers to L1 declared in the #enclosing scope of G1 } GlobalPlist G2 { LocalPList L2 { } GlobalPListG3 { LocalPList L3 { } PList L1; # Error. No L1 declared in this or anyenclosing # scope; # Error. The name L2 is not declared in this scope.Also # though L2 is declared in the enclosing scope, this scope # isglobal, and so no further enclosing scope is examined. # # Contrast withreference to name L2 in LocalPList L3 below. PList L2; PList G1.L1; #OK. Refers to L1 in G1. # Error. G3 is not really nested inside G1.Since G3 # is global, it is really declared at an outermost level, # andso G1.G3 is meaningless. PList G2.G3.L3; } LocalPList L3 { # OK. Refersto G2.L2. The enclosing global scope is G2 # and the name L2 is declaredin G2. PList L2; } }

[0763] All pattern list file names and pattern file names are requiredto be unique across the test plan using them.

[0764] A pattern list reference can refer to a pattern list definedeither before or after the reference in the same file.

[0765] Recursive and mutually recursive pattern list definitions are notpermitted. While there is nothing in the pattern list file syntax toprevent the user from creating such definitions, the parser will flag anerror when it detects such conditions. Note that there is some costassociated with the detection of such conditions. The user will be ableto switch off the check if s/he can assume the responsibility ofguaranteeing that the input space is free from mutually recursivedefinitions. GlobalPList G1 { LocalPList L2 { LocalPList L3 { # Error.L2 runs L3 which runs L2. # This is a recursive reference to L2 PListL2; PList G2; } } } GlobalPList G2 { # Error. G1.L2 runs L3 which runsG2 which runs G1.L2. # This is a mutually recursive reference to G1.L2.PList G1.L2; }

[0766] The syntactic description of patterns and pattern lists allowsfor options to be specified on them. In general options are vendorspecific. The syntax allows for any pattern or pattern list to have anumber of options specified, each with a number of parameters. In wedescribe some supported options that will be recognized by most vendors.

[0767] The dynamic (i.e., execution) semantics of pattern trees isdescribed in after defining a pattern execution sequence.

[0768] E2. Patterns

[0769]FIG. 6 illustrates a pattern compiler 602 and a pattern loader 604according to an embodiment of the present invention. The user-definedcontents of a pattern are available in a pattern source file 606, whichis a plain text file. A pattern compiler will be responsible forcompiling a source file into a module-specific format suitable forloading on the tester hardware; this latter file will be referred to asthe pattern object file. The following are the general attributes:

[0770] 1. A Pattern object is not creatable by the user; rather, theuser always deals with pattern lists, which are collections of otherpattern lists and/or patterns. A pattern list object creates, owns andmaintains the pattern objects contained within it, while making themaccessible to the user if necessary.

[0771] 2. A pattern is uniquely named within a test plan, i.e., no twopatterns within the test plan. can have the same name. The name of apattern is distinct from the name of the file containing it. The patternfile name is the one used in the pattern list file to refer to apattern, while the actual name of the pattern is defined in the patternfile.

[0772] In an embodiment of the invention, in general, a single DUT(device-under-test) might be connected to tester modules from differentvendors. This has implications for the entire patterncompile-load-execute chain. The main ones are described in this section.

[0773] E3. Pattern Compilation

[0774] A pattern compiler 602 thus needs to target a specific siteconfiguration (in terms of the vendor-specific digital modules used).For the rest of this discussion, the term “module” will be used to referto a digital module, as an example. In order to allow the integration ofmodules 608 from different vendors into the system, the followingprocedures are preferred:

[0775] 1. Each module vendor will be responsible for providing its ownmodule-specific pattern compiler 610, in the form of a dynamicallyloadable library or separate executable. This compilerlibrary/executable will provide, at the very least, a well-knowncompile( ) function that takes as arguments

[0776] a. an array of (one or more) pattern source file pathnames,

[0777] b. the Pin Description file name,

[0778] c. the Socket file name,

[0779] d. an optional directory pathname specifying the destination ofthe compiled object,

[0780] e. an optional array of string name/value pairs that allow thespecification of any vendor-specific parameters (that can be ignored byother vendors).

[0781] 2. The pattern source file will accommodate two different typesof sections:

[0782] a. a “common” section that will contain information accessible to(but not necessarily used by) all compilers, and

[0783] b. one or more optional vendor-specific sections, each identifiedby unique vendor codes, for information usable by specific vendors'compilers.

[0784] 3. A vendor's compiler will not directly create a pattern objectfile. Instead, the tester will provide for a pattern object “metafile”612, managed by an Object File Manager (OFM) 614, which is part of thepattern compiler. The pattern compiler may be located on the computeracting as the system controller, or offline, e.g., on a network to whichthe system controller is connected. The “pattern object file” referredto so far in abstract terms is actually this object metafile. The objectmetafile will be named the same as the pattern source file, with thesource file extension replaced by the object file extension. The OFMwill provide an application programming interface (APIs) to read andwrite this file. The object metafile will have provisions for storing

[0785] a. common header information,

[0786] b. module-specific header information, including informationidentifying the corresponding module and the location of pattern datafor the module,

[0787] c. module-specific pattern data, organized as required by themodule vendor, and capable of being interpreted by the module vendor.

[0788] The OFM APIs will allow a module vendor's compiler to writemodule-specific header information and data into the object metafile.Note that this layout of the object metafile allows the pattern data tobe organized on a per-module basis, even in the case where two or moremodules in the targeted site are identical.

[0789] Note that additional vendor-supplied configuration informationmight be needed by pattern compilers to facilitate the generation ofmodule-specific hardware loading information that can take advantage ofefficient data communications such as direct memory access (DMA).

[0790] E4. Pattern Load for a Module

[0791] Each module vendor will be responsible for providing its ownpattern loading mechanism 615, following the general procedure. Thepattern object metafile 612 of a module 608 stores module-specific datain different sections 616. The vendor implementation will use the OFMAPIs for accessing the relevant module-specific sections from thepattern object metafile. The tester framework will be responsible forcalling each module's load method in turn to load module-specific datato a module from the appropriate section of the metafile.

[0792] E5. Pattern Files

[0793] It is possible to have each compiler vendor specify entirelydifferent plain text formats for patterns, which, in fact, might indeedbe necessary in most cases. However, in general, for a cycle-basedtesting environment, where coherent and identical semantics acrossmodules are necessary for every vector, a shared, generalized syntax forthe pattern file is not only desirable, but may be necessary. Thisshared syntax is what will be specified for the “common” section in thepattern source file. In fact, for the majority of cases, it isenvisioned that the “common” section is the only section (besides headerinformation) that will be required in the pattern file, and everyvendor's compiler will work with only that section. This sectionpresents rules for the pattern file that all compilers should be able tointerpret. The pattern file will be organized as follows: file_contents: version_info pattern_definitions version_info : Versionversion-identifier ‘;’ pattern_definitions pattern_definitionpattern_definitions pattern_definition pattern_definition : main_header‘{’ main_section ‘}’ main_header ‘{’main_section vendor_sections ‘}’subr_header ‘{’ subr_section ‘}’ subr_header ‘{’ subr_section vendor_sections ‘}’ main_header : MainPattern identifier main_section :CommonSection ‘{’ common_contents main_section_domains ‘}’common_contents : timing_reference timing _map_referencetiming_reference : Timing file-name ‘;’ timing_map_reference : TimingMapfile-name ‘;’ main_section_domains : main_section _domainsmain_section_domain main_section_domain main_section_domain : Domaindomain_name ‘{’ main_section_contents ‘)’ domain_name : identifiermain_section_contents : main_section_contents main_section_contentmain_section_content main_section_content : label_spec main_pattern_specmain_pattern_spec label_spec : label ‘:’ label : identifiermain_pattern_spec : main_operation capture_mask_flag ‘{’vectors_and_waveforms ‘}’ main_operation : /* empty */ common_operationjal_op jsr_op jsrc_op jsc_op exit_op common_operation : idxi_op idxin_opjec_op jech_op jff_op jffi_op jni_op ldin_op nop_op pause_op sndc_opsndt_op stfi_op sti_op stps_op wait_op /*  * Instructions specific tothe MAIN Patterns  */ jsr_op : JSR identifier jsrc_op : JSRC identifierjsc_op : JSC identifier jal_op : JAL identifier exit_op : EXIT /*  *Instructions common to both MAIN and SUBR Patterns  */ idxi_op : IDXI24-bit number idxin_op : IDXIn index-register jec_op : JEC identifierjech_op : JECH identifier jff_op : JFF identifier jffi_op : JFFIidentifier jni_op : JNI identifier ldin_op : LDIN index-register nop_op: NOP pause_op : PAUSE sndc_op : SNDC 8-bit number sndt_op : SNDT 8-bitnumber stfi_op : STFI 24-bit number sti_op : STI 24-bit number stps_op :STPS wait_op : WAIT capture_mask_flag : /* empty */ capture _mask_flagCTV capture _mask_flag MTV capture _mask_flag MATCHvectors_and_waveforms : /* empty */ vectors_and_waveforms vectorvectors_and_waveforms waveform vector : vector_declaration ‘{’vector_data ‘}’ vector_declaration : Vector V vector_data : vector_datumvector_data vector_datum vector_datum : pin_name ‘=’ vector-value ‘;’pin_name ‘=’ identifier ‘;’ waveform : waveform_declaration‘{’waveform_data ‘}’ waveform_declaration : Waveform W waveform_data :waveform_datum waveform_data waveform_datum waveform_datumwaveform-table-pin-group-name ‘=’ identifier ‘;‘ pin_name : : identifiervendor_sections vendor_sections vendor_section { } vendor_section { }vendor_section : VendorSection ‘{’ vendor_section_contents ’}’subr_header : SubrPattern subr_section : CommonSection ‘{’common_contents source_selection_table subr_section_domains ‘}’CommonSection ‘{’ common_contents subr_section_domains ‘}’subr_section_domains : subr_section_domains subr_section_domainsubr_section_domain subr_section_domain : Domain domain_name ‘{’subr_section_contents ‘}’ source_selection_table : SourceSelectionTable‘{’ source _selector_definitions ‘}’ source_selector_definitions:source_selector_definitions source_selector_definitionsource_selector_definition source_selector_definition: SourceSelectorsource_selector_name ‘{’ source_mappings ‘}’ source_selector_name :identifier source_mappings : source_mappings source_mappingsource_mapping source_mapping : pin_name ‘=’ source ‘;’ source : MAININVERT_MAIN SUBR INVERT_SUBR subr_section_contents :subr_section_contents subr_section_content subr_section_contentsubr_section_content : label_spec subr_pattern_spec subr_pattern_specsubr_pattern_spec : subr_operation capture _mask_flag ‘[’vectors_and_waveforms ‘}’ subr_operation : /* empty */ common_operationrtn_op stss_op /*  * Instructions specific to the SUBR Patterns  */rtn_op : RTN stss_op : STSS identifier

[0794] The following are the descriptions of undefined non-terminalsused above:

[0795] 1. version-identifier: A sequence of one or more characters fromthe set [0-9.], where the first character must be a digit.

[0796] 2. identifier: A sequence of one or more characters from the set[a-zA-Z_(—)0-9], where the first character must be from the set[a-zA-Z_].

[0797] 3. vendor-section-contents: Arbitrary text that is meaningfulonly to a vendor-specific compiler.

[0798] 4. file-name: A valid Windows file name (must be enclosed indouble quotes if any white-spaces are contained in the file name). Notethat this should be a simple file name, i.e., it should not have adirectory component.

[0799] 5. waveform-table-pin-group-name: A sequence of one or morecharacters from the set [a-zA-Z_(—)0-9], where the first character mustbe from the set [a-zA-Z_]. This variable is declared elsewhere and holdsthe name of the waveform-table that is common to a group of pins.

[0800] 6. 24-bit number: A valid decimal number up to a maximum of16777215.

[0801] 7. 8-bit number: A valid decimal number up to a maximum of 256.

[0802] 8. index-register: A valid decimal number. In one embodiment of amodule this can have a value [1-8].

[0803] 9. vector: This is similar to the Vector statement in STIL. Notethat this refers to signal names and signal groups names, making itnecessary for the compiler to have access to the Pin Description file.

[0804] 10. waveform-time-reference: A sequence of one or more charactersfrom the set [a-zA-Z_(—)0-9], where the first character must be from theset [a-zA-Z_].

[0805] Pattern files will support comments, which are meant to beignored by a pattern file compiler. Comments will start with the ‘#’character, and extend to the end of the line.

[0806] The following points should be noted with reference to theconstructs in the pattern file's header and “common” sections:

[0807] 1. The pattern-name item specifies the name that will beassociated with the Pattern object that the pattern file contains thedata for. This gets carried over to the header in the correspondingpattern object metafile.

[0808] 2. The waveform-time-reference is the name for a particularwaveform-and-timing definition that would be defined externally to thepattern file, in the Timing file. The specification of awaveform-time-reference in the pattern file would bind that particularname (for a waveform-and-timing) to all subsequent vectors, untilanother waveform-time-reference were encountered.

[0809] 3. The operand for a subroutine call (e.g., JSR and JSRC) is astring that should either be a pattern-spec label previously encounteredin the same pattern file, or a pattern-spec label in an externallydefined subroutine pattern. This operand will ultimately be resolved forthe purposes of loading/handling subroutines. The labels for subroutinecall operands are required to be unique across the system.

[0810] Note that while waveform-time-reference names could be anythingthat is syntactically correct, due to specific hardware implications thewaveform-time-reference names may need to be restricted to a previouslyknown, well-defined set (which, for added readability, can be optionallymapped by the user to user-chosen names, the mapping presented in anoptional file).

[0811] Also note that the pattern and waveform-time-reference sourcefiles should provide initial configuration data for all DUT channelswhich have connections to physical tester channels. If subsequent datais omitted for any DUT channel, the pattern compiler will “pad” thepattern data to hold output from the initial level.

[0812] Pattern File Example

[0813] A simple example of a MAIN Pattern source file will helpillustrate the usage. # # Filename : good1.pat # Version 1.0 ; #---------------------------------------------------------------------- #Main Pattern definition: #----------------------------------------------------------------------MainPattern good1 { CommonSection { MacroDef defaultDataVal (XXXXXXXX)MacroDef nopInstr (NOP) MacroDef label1 (Label1 : ) MacroDef jniInst(JNI) #------------------------------------------------------------------ #Timing Specifications #------------------------------------------------------------------Timing “productionTiming.tim”; TimingMap“productionTimingOpenSTARMap.tmap”; #------------------------------------------------------------------ #Default Domain Cycles #------------------------------------------------------------------Domain default { #---------------------------------------------------------------- #label: instruction {Vector/Waveform Data} #---------------------------------------------------------------- NOP { V{ DATA = $defaultDataVal; CLK = 1;} W { DATA = wfsl; CLK = wfsl; } } JALmyAPG { V { DATA = 00000000; } } JSC mySCAN { V { DATA = 10101010; } }JSRC mySubroutine { V { DATA = 01010101; } } JSR myAPG { V { DATA =00110011; } } STI 100 { } labZero: NOP { V { DATA = 00000011; } } JNIlabZero { V { DATA = 11111100; } } IDXI 3000 { V { DATA = 10101010; } }IDXIn 3 { V { DATA = 01010101; } } $label1 NOP { V { DATA =$defaultDataVal; } } IDXI 2000 { V { DATA = 10101010; } } NOP { } EXIT {V { DATA = LLHHLLHH; } } } } }

[0814] Another example illustrating a SUBROUTINE pattern source file isillustrated below.#-------------------------------------------------------------------- #Subroutine Pattern mySubrPat1 definition:#--------------------------------------------------------------------SubrPattern mySubrPat1 { CommonSection {#---------------------------------------------------------------- #Timing Specifications#---------------------------------------------------------------- Timing“productionTiming.tim”; TimingMap “productionTimingOpenSTARMap.tmap”;#---------------------------------------------------------------- #Source Selection Specifications#----------------------------------------------------------------SourceSelectionTable { SourceSelector SrcSelDef { DATA=SUBR; CLK=SUBR;DATA=SUBR; } SourceSelector SrcSelOne { DATA=MAIN; CLK=MAIN; } }#---------------------------------------------------------------- #Default Domain Cycles#---------------------------------------------------------------- Domaindefault {#---------------------------------------------------------------- #label: instruction { Vector and Waveform Data setups }#---------------------------------------------------------------- STI100 { Vector { DATA = 00000000; } } IDXI 3000 { Vector { DATA =00001111; } } IDXIn 3 { Vector { DATA = 00110011; } } $label1 NOP {Vector { DATA = LLHHLLHH; } } NOP { Vector { DATA = LLXXXXXX; } } NOP {Vector { DATA = LLHHXXXX; } } JNI Label1 { Vector { DATA = LLHHLLHH; } }STSS SrcSelOne { Vector { DATA = LHLHLHLH; } } RTN { Vector { DATA =LLXXXXXX; } } } } }

[0815] Summary information from the main header and common section inthe pattern source file is stored in the main header in the objectmetafile. The summary consists of information that is typically requiredfor quick extraction to aid pre-load resolution of addresses, etc., orto aid in datalogging. Since the semantics of the common section areexactly the same for all compilers, every compiler will be capable ofproviding the same summary information, and the first compiler writingthe metafile will store this information. The following is theinformation that will be stored:

[0816] 1. The pattern source file name.

[0817] 2. The type of the pattern as declared in the source file.

[0818] 3. The version information from the source file.

[0819] 4. A list of all the waveform-and-timing names used in thepattern source file's common section.

[0820] 5. A map of all subroutine references to (relative) vectoraddresses in the pattern source file's common section.

[0821] 6. A map of all label references to (relative) vector addressesin the pattern source file's common section.

[0822] 7. General bookkeeping information: vector count, instructioncount, etc.

[0823] The open architecture test system requires both pattern andpattern list files to have explicit, and different, extensions. Forpattern files, this applies to both plain text source and compiledobject files. This is viewed as a convenience to the user to quicklyidentify the file type visually in a directory listing, etc., as well asallow associations to be made on the basis of extensions. The patternlist file parser will expect filenames with these extensions: Plain textpattern source file: .pat Compiled pattern object metafile: .pobjPattern list file: .plst

[0824] The user can override these default values, e.g., through testerenvironment variables or setup options.

[0825] The tester will require the definition of the following“environment” variables for file search paths in at least one of theenvironment configuration files described in: Tester_PATLIST_PATH: Forpattern list files. Tester_PATSRC_PATH: For pattern source files(optional). Tester_PATOBJ_PATH: For pattern object metafiles.

[0826] Note that if the optional environment/setup variableTester_PATSRC_PATH is not defined, it will be assumed to be the same asTester_PATOBJ_PATH. In general, it would be more efficient to not defineTester_PATSRC_PATH rather than define it with the same value asTester_PATOBJ_PATH.

[0827] E6. Software Representation

[0828] A Pattern object is not created by the user; rather, the useralways deals with Pattern List objects, which are collections of otherpattern lists and/or patterns. A Pattern List object creates, owns andmaintains the pattern objects contained within it, while making themaccessible to the user. A pattern list object in the user's test programis associated with a pattern list file on disk, which contains theactual definition of the pattern list. The definition of a pattern listprovides an explicit name for the pattern list, and identifies anordered list of patterns and/or other pattern lists through file nameassociations. This section describes the software representation ofpattern lists and patterns, as a prelude to understanding how they aremanipulated in the tester framework.

[0829] Pattern List Associations

[0830] A single test site in the test system (and, by extension, thetest plans in it) can be associated with multiple top-level patternlists. However, there is only a single execution context for test plansat any given time. Since a top-level pattern list defines an executionsequence for the patterns referred to (hierarchically) by it, the activeexecution context is the one corresponding to the currently selectedtop-level pattern list. Note that this does not imply that only thepatterns contained in a single pattern list can be loaded on thehardware at one time; rather, the set of patterns that are required tobe loaded on the hardware to make an execution sequence viable mustalways be a subset of all the currently loaded patterns.

[0831] Pattern Trees

[0832] Intuitively, it is felt that a way to represent a top-levelpattern list is by some sort of a tree data structure. FIG. 7illustrates an embodiment of an ordered pattern tree of the invention,assuming that the pattern list A is the top-level pattern list

[0833] Pattern Tree Information Content

[0834] The following information will be stored at every node of thepattern tree:

[0835] 1. The name of the entity (pattern-list or pattern) associatedwith that node.

[0836] 2. The type of the definition source. For a leaf (pattern node),this will always be a pattern file; for an intermediate (pattern list)node, this could be either “top-level file” (for top-level pattern listdefinitions) or “embedded in file” (for nested pattern-listdefinitions).

[0837] 3. The last modification timestamp of the file on disk the nodeis associated with.

[0838] The following additional information will be stored only inintermediate (pattern list) nodes:

[0839] 1. Execution options (if any) set on the pattern-list objectrepresented by that node—i.e., its object options.

[0840] 2. The execution options (if any), set on each child referenceinside the pattern list definition represented by that node—i.e., thereference options, for each of its children.

[0841] Thus, the collection of nodes encountered on the unique path fromthe root to an intermediate node, and the sequence in which they areencountered, contain all the information necessary to determine thecombined, effective, execution options represented by that node. Theexecution options of a pattern are determined by the effective executionoptions of its immediate parent, combined with the reference options itsimmediate parent might have for it.

[0842] It should be noted here that while the pattern list parser is inthe process of creating the pattern tree, certain execution optionsmight require initial storage of values simply as strings, since thecontext of their use might not be resolved until later. An example ofsuch an option is a “mask” option, which specifies pin mask information:pattern lists are not associated with Socket information, and hence, pinmask options (pin and group names) are stored as strings, to be resolvedprior to loading.

[0843] The following additional information will be stored only in leaf(pattern) nodes:

[0844] 1. All (possibly transitive) references to subroutines called bythat pattern, both external and internal, organized as an executiontree.

[0845] Of course, all pattern nodes will additionally have access to—andmight choose to cache—all the pattern file summary information availablein the object metafile common header.

[0846] Handling Pattern List Modifications

[0847] Changes made to the contents of a pattern list conceptuallyaffect all references to that pattern list. The following rules, whichapply as appropriate to pattern objects as well as pattern list objects,will be used to manage such changes:

[0848] 1. A change made to the contents of a pattern list file on diskwill be propagated through the test system only on a load( ) commandbeing executed on that pattern list (or on any other pattern list thatreferences that one). In other words, the pattern list hierarchy insoftware will always reflect the one currently loaded on the hardware.

[0849] 2. The user will be able to set a mode that will defeat thechecks made during load time to synchronize pattern lists with theirdisk file sources; this will allow quicker/safer operation in productionmode.

[0850] Pattern Tree Navigation

[0851] The top-level pattern lists associated with a test site (and, byextension, with a test plan for that site) have public (global) scope.The system provides APIs to navigate the pattern tree representing atop-level pattern list so that users can get access to individual nodesand sub-trees.

[0852] E7. Pattern List Dynamics

[0853] Earlier the static rules of Pattern Lists were described. Adescription of the dynamic (execution) rules of pattern lists is nowpresented.

[0854] The pattern tree is essential for general pattern management. Forexample, the starting point for a pattern load sequence is a call to theload( ) method on the pattern tree currently associated with the site ortest plan. However, a pattern tree does not operate in isolation. Afully initialized pattern tree will be used to create the following twoframework objects:

[0855] 1. A top-level pattern list defines a Pattern Execution Sequencefor the patterns. It describes how such an execution sequence can bederived from the pattern tree corresponding to that top-level patternlist. For example, the pattern execution sequence corresponding to thepattern tree A shown in FIG. 7 is {q, s, t, q, r, q, u, u, v}. ThePattern Execution Sequence is conceptually an ordered list reflectingthe execution sequence described through the pattern tree. The frameworkestablishes and maintains any necessary navigation links between patterntree nodes and corresponding entries in the Pattern Execution Sequence.

[0856] 2. The Pattern Set, which is simply a list of all the uniquepatterns (including subroutines) in the pattern tree. This is thus thelist that will be used to determine the individual patterns that shouldbe loaded on the hardware. The framework establishes and maintains anynecessary navigation links between pattern tree nodes and correspondingentries in the Pattern Set. The Pattern Set for the pattern tree of FIG.7 is (q, s, t, r, u, v) (it is assumed that none of the patterns inpattern list A contain any subroutine calls):

[0857] Note that both the Pattern Execution Sequence and the Pattern Setcan always be derived from the pattern tree; however, it would oftenmake sense to cache them, after initial construction, for as long wasviable.

[0858] Pattern List Execution Options

[0859] As shown above, each pattern list declaration (preceding itsdefinition) or pattern list/pattern reference entry can be followed by anumber of execution options. Pattern list execution options modify theruntime execution of pattern lists. To allow future extensions, thenames (and optional values) for these options will be treated simply asstrings by the pattern list file parser of the pattern compiler, to beinterpreted by a particular version as appropriate. Tester prescribes aset of options and their interpretations, described below. However,vendors can extend the set of options. In order to allow a parse-timevalidation of option syntax, the pattern list file parser could read aninformation file for a particular version. Such an information filecould also be used to specify whether a particular version at allsupports the specification of execution options.

[0860] For versions that support a set of execution options, thefollowing general rules will govern their use. In order to understandthese rules, it is useful to visualize the hierarchical collection ofpattern lists/patterns as an ordered tree.

[0861] 1. Intrinsic options set on pattern list definitions (i.e., inthe “local-pattern-list-declaration, global-pattern-list-declaration”productions in the file are, in effect, direct option settings on thecorresponding Pattern List object in the user's test program. They thusapply to all references to that pattern list object, and are referred toas object options.

[0862] 2. Referential options set on references to patternlists/patterns (i.e., in the “pattern-entry” and “pattern-list-entry”productions in the file limits the scope of the options to a specificpath in the hierarchy—the path (established by the declaration order ofpattern lists/patterns) that leads from the root of the tree to thereference under consideration. These are thus options on specific objectreferences (and not on the objects themselves), and are referred to asreference options.

[0863] 3. The effective option settings for any list/pattern in thecollection hierarchy (established by the declaration order of patternlists/patterns) are a combination of the object and reference optionsencountered along the path from the root of the tree to thatlist/pattern. The specific combination mechanism (e.g., set union, setintersection, or any other conflict resolution algorithm) is a propertyof the option itself.

[0864] Note that a consequence of the above rules—and the fact thatthere is no facility to set execution options on a pattern definition ina pattern file—is that there is no direct rule to set options whichapply to all references to a pattern. The mechanism for achieving thisis to use a single-pattern pattern list.

[0865] The tester specifies a certain set of pattern list executionoptions that modify its burst behavior, and that modify its executionsequence.

[0866] When an execution sequence for a pattern list is submitted to thehardware, the hardware produces a burst. A Burst is the execution of asequence of patterns directly by the hardware, without any involvementfrom the software. A Burst Discontinuity is a position in an executionsequence where a prior burst is terminated, and a new burst is started.

[0867] One of the objectives of the pattern management software is toprovide the hardware with the execution sequences that it needs toproduce a burst on. By default, a pattern tree yields an executionsequence, which if submitted to the hardware will result in a singleburst. This behavior can however be modified by the use of options onthe pattern list. Thus, the use of options result can result in burstdiscontinuities.

[0868] Furthermore, users will sometimes require a prologue or epiloguepattern to be run before or after every pattern or every burst. Thismodifies the execution sequence to be submitted to the hardware.

[0869] During the creation or modification of the Pattern ExecutionSequence object, the framework has all the information necessary todetermine, and report if required, breaks in pattern bursts resultingfrom the combination of execution options specified and the particularexecution sequence embodied by the pattern tree. While doing this, itmight need to investigate the hardware capabilities of the modules inthe system. For example, one hardware implementation allows four storedconfigurations for pin masks, of which two (0 and 3) are used fordefault masked (to support Mask This Vector, MTV) and unmaskedoperation. The user is thus allowed two different global pin-maskconfigurations without breaking burst mode.

[0870] Note that if a module vendor does not support pattern listimplementations in hardware, the vendor's processing of the PatternExecution Sequence would result in individual execution of all patternsin the execution sequence. In both Site-Compatible andSite-Heterogeneous systems, the burst capability of sites would belimited by the “lowest common denominator”. The tester provides for acertain default set of options and their parameters is described below.Each option is specified by stating:

[0871] Whether it is Intrinsic (i.e. associated with a definition withthe Global or Local keyword) or Referential (i.e. associated with areference with the Pat or PList keyword). Intrinsic options apply at thepoint of definition and at every reference, but referential optionsapply only at the reference they are associated with.

[0872] Furthermore, an option is said to be Inherited by Children if theoption is assumed to apply recursively to all statically (syntactically)or dynamically (semantically by being referenced) nested patterns orpattern lists.

[0873] Below is the list of options. Every compliant vendor willinterpret these options as specified.

[0874] 1. Mask <pin/pin group>

[0875] Intrinsic when applied to GlobalPList, LocalPList

[0876] Referential when applied to PList, Pat.

[0877] Inherited by children.

[0878] This pattern list will always have the compare circuits of thepins referred to by the indicated pin or pin group disabled. Sometimes,hardware limitations may result in burst discontinuities.

[0879] 2. BurstOff

[0880] Intrinsic when applied to GlobalPList, LocalPList

[0881] Referential when applied to PList, Pat.

[0882] Not inherited by children.

[0883] This pattern list will always execute in the non-burst mode. Thisoption is not inherited by children, but the BurstOffDeep option (below)is inherited by children.

[0884] 3. BurstOffDeep

[0885] Intrinsic when applied to GlobalPList, LocalPList

[0886] Referential when applied to PList, Pat.

[0887] Inherited by children.

[0888] This pattern list will always execute in the non-burst mode. Thisoption is inherited by children, but the BurstOff option (above) is notinherited by children. Note that the BurstOffDeep option cannot beturned off by a child.

[0889] 4. PreBurst <pattern>

[0890] Intrinsic when applied to GlobalPList, LocalPList

[0891] Inherited only by child nodes having no burst options specified.

[0892] The indicated pattern is to be prefixed to all bursts within thispattern list.

[0893] The PreBurst pattern occurs just before every burst that isstarted due to this pattern list node. The option is not applied whenalready within a burst which has a PreBurst option that is the samepattern.

[0894] 5. PostBurst <pattern>

[0895] Intrinsic when applied to GlobalPList, LocalPList

[0896] Inherited only by child nodes having no burst options specified.

[0897] The indicated pattern is to be suffixed to all bursts within thispattern list.

[0898] The PostBurst pattern occurs just after every burst that isstarted due to this pattern list node. The option is not applied whenalready within a burst which has a PostBurst option that is the samepattern.

[0899] 6. PrePattern <pattern>

[0900] Intrinsic when applied to GlobalPList, LocalPList

[0901] Not inherited by children.

[0902] The indicated pattern is to prefixed to all patterns within thispattern list.

[0903] 7. PostPattern <pattern>

[0904] Intrinsic when applied to GlobalPList, LocalPList

[0905] Not inherited by children.

[0906] The indicated pattern is to be suffixed to all patterns withinthis pattern list.

[0907] 8. Alpg <alpg object name>

[0908] Intrinsic when applied to GlobalPList, LocalPList

[0909] Not inherited by children.

[0910] The named ALPG object stores relevant information such as slowspeed APG register settings, read latency, immediate data registers,address scramble, data inversion, data generators, etc.

[0911] 9. StartPattern <pattern>

[0912] Intrinsic when applied to GlobalPList, LocalPList

[0913] Not inherited by children.

[0914] The pattern list will start executing at the first occurrence ofthe StartPattern in its execution sequence.

[0915] 10. StopPattern <pattern>

[0916] Intrinsic when applied to GlobalPList, LocalPList

[0917] Not inherited by children.

[0918] The pattern list will stop executing at the first occurrence ofthe StopPattern in its execution sequence.

[0919] 11. StartAddr <vector offset or label>

[0920] Intrinsic when applied to GlobalPList, LocalPList

[0921] Not inherited by children.

[0922] This must be accompanied by a StartPattern option. The patternlist will start executing at the StartAddr in the first occurrence ofthe StartPattern in its execution sequence.

[0923] 12. StopAddr <vector offset or label>

[0924] Intrinsic when applied to GlobalPList, LocalPList

[0925] Not inherited by children.

[0926] This must be accompanied by a StopPattern option. The patternlist will stop executing at the StopAddr in the first occurrence of theStopPattern in its execution sequence.

[0927] 13. EnableCompare_StartPattern <pattern>

[0928] Intrinsic when applied to GlobalPList, LocalPList

[0929] Not inherited by children.

[0930] Pattern comparison will commence at the first occurrence of theindicated pattern.

[0931] 14. EnableCompare_StartAddr, EnableCompare StartCycle

[0932] Intrinsic when applied to GlobalPList, LocalPList

[0933] Not inherited by children.

[0934] This must be accompanied with EnabelCompare_StartPattern.Indicates the address or cycle within the pattern where patterncomparison is to start.

[0935] 15. EnableCompare_StopPattern <pattern>

[0936] Intrinsic when applied to GlobalPList, LocalPList

[0937] Not inherited by children.

[0938] Pattern comparison will complete at the first occurrence of theindicated pattern.

[0939] 16. EnableCompare_StopAddr, EnableCompare_StopCycle

[0940] Intrinsic when applied to GlobalPList, LocalPList

[0941] Not inherited by children.

[0942] This must be accompanied with EnableCompare_StopPattern.Indicates the address or cycle within the pattern where patterncomparison is to complete.

[0943] 17. Skip.

[0944] Referential when applied to PList, Pat.

[0945] Not inherited by children.

[0946] Causes a pattern or the entire subsequence dominated by a patternlist to be skipped. This will also cause skipping of all options at theroot of this pattern list sub-tree. It is as if this pattern sub-treewere not there for execution purposes.

[0947] Pattern List Burst Control

[0948] As described earlier, when an execution sequence for a patternlist is submitted to the hardware, the hardware produces a burst of asequence of patterns, without any involvement from the software. A BurstDiscontinuity is a position in an execution sequence where a prior burstis terminated, and a new burst is started. The PreBurst, PostBurst,BurstOff and BurstOffDeep options control where the burstdiscontinuities occur, as described in the option list above. PreBurstand PostBurst options determine burst discontinuities subject to certainadditional rules described below:

[0949] 1. When a parent list has PreBurst and PostBurst options, and thenested list has the same corresponding options, there is no burstdiscontinuity, and the PreBurst and PostBurst options of the nested listdo not apply. There is only a single burst applying the PreBurst and thePostBurst of the parent list.

[0950] 2. Notice that when the nested list has no burst options, it isequivalent to having the same PreBurst and PostBurst options as theparent list by the description of these options. Consequently, nestedlists with no burst options do not result in a burst discontinuity.

[0951] 3. If rule 1 above does not apply and there is a contribution tothe pattern execution sequence from the start of the parent list to thestart of the nested list, then there is a burst discontinuity at thestart of the nested list. In this case the PreBurst and PostBurst of theparent list apply to this contribution to the pattern execution sequencefrom the parent list. The PreBurst and the PostBurst of the nested listapply to the nested list.

[0952] 4. If rule 1 above does not apply, and there is a contribution tothe pattern execution sequence from the end of the nested list to theend of the parent list, then there is a burst discontinuity at the endof the nested list. In this case the PreBurst and PostBurst of theparent list apply to this contribution to the pattern execution sequencefrom the parent list. The PreBurst and the PostBurst of the nested listapply to the nested list.

[0953] 5. If rule 1 does not apply, and there is no contribution to thepattern execution sequence from the parent list other than from thenested list, then the PreBurst and the PostBurst of the parent list donot apply. There is only a single burst applying the PreBurst andPostBurst of the nested list.

[0954] Below are a few examples illustrating the effect of options onthe execution sequence. To simplify, it is assumed that all the patternlists are specified in a single file.

EXAMPLE 1 Use of BurstOff

[0955] This example illustrates BurstOff and PreBurst. Of particularemphasis is that BurstOff causes patterns to run singly in bursts thatare one pattern long. Hence the PreBurst option still applies. The inputpattern lists are as below: Global A [BurstOff] [PreBurst pat_z] { Patq; PList B; Pat r; Pat s; Global C { Pat t; Plist D; }; Plist D; PListE; }; Global B { Pat a; Pat b; }; Global D [BurstOff] { Pat c; Pat d; };Global E { Pat e; };

[0956] The tree rooted at A may be represented in FIG. 8.

[0957] The execution sequence for this pattern is below. The | characterindicates a burst break. This pattern list executes in 10 bursts, thefirst one having patterns z and q, and the last one with pattern e:

[0958] z q | a b | z r | z s | t | c | d | c | d | e

[0959] Note the following about this execution sequence:

[0960] 1. Since the BurstOff option on A is not inherited by B, thepatterns a and b in B operate as a burst.

[0961] 2. Since the PreBurst option on A is not inherited by B, the aand b in the burst by B is not prefixed by z.

[0962] 3. The prefix by z only happens for the patterns that areexecuted due to being direct children of a, namely patterns q, r and s.These patterns are executed singly as if in a burst that is only onepattern long due to A having the BurstOff option. The BurstOff requirespatterns to be run individually in one-pattern long bursts. Hence, thePreBurst and PostBurst options still apply.

[0963] 4. Pattern list D has an intrinsic burst off option that causesits children c and d to execute singly. They do not inherit the PreBurstz from A.

EXAMPLE 2 Use of BurstOffDeep

[0964] This example illustrates the BurstOffDeep option. BurstOffDeepduring pattern list definition affects nested definitions and referencedlists. However, PreBurst and PostBurst options are not inherited bynested and referenced lists. The example uses the same patterns A, B, C,D, E as in example 1, but the options are different:

[0965] 5. Options on definition of A: [BurstOffDeep], [PreBurst z],[PostBurst y]

[0966] 6. No other options on any other node.

[0967] The execution sequence is as below. As earlier, the | characterindicates a burst break.

[0968] z q y | a | b | z r y | z s y | t | c | d | c | d | e

[0969] Note the following about this execution sequence:

[0970] 1. PreBurst and PostBurst are not inherited by B, C, D, E.

[0971] 2. BurstOffDeep is inherited by B, C, D, and E.

EXAMPLE 3 PreBurst and PostBurst Inhibition

[0972] Suppose now the pattern list tree of Example 1 is considered,where the options are:

[0973] 1. Options on definition of A: [PreBurst x] [PostBurst y]

[0974] 2. Options on definition of C: [PreBurst x] [PostBurst z]

[0975] 3. No other options on any other node.

[0976] The execution sequence would be:

[0977] x q a b r s t c d c d e y

[0978] The reasons why the “t c d” subsequence is not “x t c d z” are asfollows:

[0979] 1. The first x is inhibited since it is equal to the pre-burstoption x that is associated with the current burst in effect.

[0980] 2. The last z is inhibited since the PostBurst z is not inheritedto D, and there is no pattern that is generated from C to which the zcan be appended.

EXAMPLE 4 Use of Skip

[0981] This example illustrates the effect of the Skip option on nesteddefinitions and referenced lists. The example uses the same patterns A,B, C, D, E as in example 1, but the options are different:

[0982] 1. Options on definition of A: [Skip], [PreBurst z], [PostBursty]

[0983] 2. Options on reference to r: [Skip]

[0984] 3. Options on definition of C: [Skip]

[0985] The execution sequence is a single burst with no breaks as below:

[0986] z q a b s c d e y

[0987] Note the following about this execution sequence:

[0988] 1. The nodes for r and C are skipped.

[0989] 2. There are no burst breaks at all.

EXAMPLE 5 Use of Mask

[0990] This example illustrates the effect of the Mask option and itseffects on pattern and pattern list definitions and references. Theexample uses the same patterns A, B, C, D, E as in example 1, but theoptions are different:

[0991] 1. Options on definition of A: [mask pin1_pin2], [PreBurst z]

[0992] 2. Options on reference of B: [mask pin3]

[0993] 3. Options on definition of B: [mask pin4]

[0994] 4. Options on reference of e: [mask pin5]

[0995] 5. No other options on any nodes.

[0996] The name “pin1-pin2” specifies a group which masks Pin1 and Pin2.The names “pin3”, “pin4” and “pin5” specify masking Pin3, Pin4 and Pin5respectively. The execution sequence is provided below, with |indicating the burst break. The numerals below each pattern indicate thepins that are masked during that pattern execution. $\begin{matrix}\left. {z\quad q\quad a\quad b\quad z\quad r\quad z\quad s\quad t\quad c\quad d\quad c\quad d}\quad \middle| \quad e \right. \\{1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1\quad 1} \\{2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2\quad 2} \\{\quad {3\quad 3\quad 5}} \\{\quad {4\quad 4}}\end{matrix}$

[0997] Note the following about this execution sequence:

[0998] 1. The vendor's hardware can only accommodate 2 mask blockswithout a burst break. Until e is executed the two mask blocks are pins{1, 2} and pins {1, 2, 3, 4}. When pattern e arrives with a differentmask block of pins {1, 2, 5}, the hardware requires a burst break.

EXAMPLE 6 Use of Inherited Options and References

[0999] This example illustrates that an inherited option at a definitiondoes not apply when the definition is referenced. Consider the followingexample: Global A { Global B [BurstOffDeep] { Global C { ... }; ... };... PList C; }; Global D { PList C; };

[1000] The BurstOffDeep option is inherited by C at its point ofdefinition. However, it is not an intrinsic option, and so it is notapplied to C at both its point of references.

EXAMPLE 7 PreBurst and PostBurst with Nested Lists

[1001] Consider the following example: GlobalPList A [PreBurst x][PostBurst y] { Pat p1; LocalPList B [PreBurst x] [PostBurst y] { Patp2; } LocalPList C { Pat p3; } LocalPList D [PreBurst x] [PostBurst z] {Pat p4; } LocalPList E [PreBurst w] [PostBurst y] { Pat p5; } Pat p6; }

[1002] The execution sequence is:

[1003] x p1 p2 p3 y | x p4 z | w p5 y | x p6 y

[1004] 1. Pattern p2 is in the same burst as p1 because the PreBurst andPostBurst options of the nested list are specified the same as theparent. Pattern p3 is also in the same burst because these options areinherited the same as the parent. These options have at least onedifferent member in the remaining nested lists, giving rise to burstdiscontinuities

[1005] Timing

[1006] The user interacts with the system primarily by defining the testsetups using pattern files. The Timing File is used to describe theTiming of these patterns. This file requires other system files (e.g.Pin, SpecSelector) for underlying definitions to be resolved. Furtherthe Spec-Selectors and Global definitions used to resolve variousvariables used in the Timing definition are encapsulated in a compositeTestConditionGroup object. Higher-level files, such as the Test Planfile, in turn use this TestConditionGroup instance.

[1007] The Test Plan File contains references to the TestConditionGroupobject. The Pattern Source File makes references to the WaveformSelectorcomponents within a TimingMap object. The Timing objects itselfreferences the Pin objects. Optionally the Timing object might alsoreference a variable modulated by a SpecSelector object. Theserelationships are illustrated in FIG. 9.

[1008] The Pattern object within the Pattern-List specifies the name ofthe WaveformSelector object to use for a set of pattern characters. Alsonote that the Timing Map file is specified in the pattern. Patterns neednot be compiled if this map is not changed.

[1009] The TestConditionGroup File objects import the Timing object touse and the TimingMap object to use. Each Test uses a TimingConditioninstance derived from the TestConditionGroup object for that instance.Thus multiple Timing objects, which support the same set of waveformtables, can be stored in the tester framework and can be swapped asrequired. Similarly multiple Test Plan Files can share a commonTestConditionGroup object.

[1010] An example of a Test Plan description file illustrates the usageof the Timing object below. Import patlist1.plist; Import tim1.tim;Import tim2.tim; Import tmap1.tmap; TestConditionGroup tim1_prod {SpecSet = prodTmgSpec(min, max, typ) { period = 10ns, 15ns, 12ns; }  Timings

TimingMap = tmap1; } } TestCondition tim1_prod_typ { TestConditionGroup= tim1_prod;   Selector = typ; } TestCondition tim2_prod_max {TestConditionGroup = tim2_prod;   Selector = max; } Test FunctionalTestMyFunctionalTestSlow { PListParam = patlist1; TestConditionParam =tim1_prod_type; } Test FunctionalTest MyFunctionalTestFast { PListParam= patList1; TestConditionParam = tim2_prod_max; }

[1011] The Timing object defines various waveforms on a per pin basis.The pins used in the Timing file and the Timing Map file need to bedefined appropriately in the Pin definition file.

[1012] The Timing object can use SpecificationSet objects to definevalues within the waveform objects. Though the Timing object can includehard-coded values for various attributes it is usually the case thatusers have various attributes be assigned values using variables. Thesevariables in turn can depend on SpecificationSet objects. An example ofthis usage is illustrated below.

}; }; Pin CLK { WaveformTable wfs1 { { 0 { U@20ns; D@40ns; } }; }; }; }

[1013] The SpecSelector is defined as illustrated below.SpecificationSet prodTmgSpec( min, max, typ) { t_le = 10ns, 14ns, 12ns;t_te = 30ns, 34ns, 32ns; ... }

[1014] The changing of the timing used by changing the spec isillustrated in the example below.

} TestConditionGroup prodTmp_max {

[1015] F2. Mapping to the Timing Components of a Tester

[1016] Two components of a tester module are directly involved with thegeneration of wave shapes and their associated timings. The two modulesare the Pattern Generator (PG) and the Frame Processor (FP). Asimplified block diagram illustrating the wave shape formatting and thetiming generation by the Frame Processor within the open architecturetest system architecture is illustrated in FIG. 10. A brief descriptionof the generation of waveforms is given below.

[1017] The Pattern Generator 1002 generates a timing set which is commonfor all the pins in the module. This timing set is called the GlobalTiming Set (GTS). There are three modes in which the Pattern Generatorcan be set up. These three modes affect the number of bits that can beused to describe the GTS. In addition these settings also impact thenumber of bits used to select a bank and whether the Capture This Vector(CTV) and Mask This Vector (MTV) bits are set or not. To instruct thetester to capture the results of this vector, the user uses the CTV flagin the Pattern file. Similarly the user uses the MTV flag in the patternto instruct the tester to mask the results of the current vector. Thisis illustrated in Table 1 below. The Pattern Generator 1002 is alsoresponsible for the generation of Waveform Characters (WFC). WFCs aregenerated on a per pin basis. The tester module uses a fixed number ofbits to describe the WFCs. TABLE 1 GTS in a GTS bits Bank GTS Bank CTVMTV 8 bits 256 4 NO NO 7 bits 128 8 YES NO 6 bits 64 16 YES YES

[1018] The tester module provides a Frame processor 1004 per pin. EachFrame Processor contains a Timing Set Scrambler (TSS) 1006, which has atotal depth of up to 1024 in this example. The TSS 1006 can bepartitioned into a number of banks 1008 depending on the mode of thePattern Generator as described earlier and illustrated in FIG. 10 where16 banks of 64 entries per bank are being used. The TSS is provided soas to allow more flexibility in the ability to define Waveform Tablesfor each pin. In the “FP” mode the TSS outputs a Timing Set using 2bits. Thus the TSS will generate a total of four distinct physicalTiming Sets per pin. These Timing Sets are referred to as the LocalTiming Sets (LTSs).

[1019] The Frame Processor 1004 combines LTS and WFC and creates anindex 1010 into the Waveform Memory 1012 and Timing Memory 1014. In the“FP” mode the 5-bit value is split up with 2 bits being generated by theLTS and 3 bits being generated by the WFC. Thus the depth of thephysical Waveform Memory and Timing Memory is 32 deep per pin though amaximum of 4 physical Timing Sets may be used. The Waveform Memorycontains the enabled timing edges that form the wave shapes. The timingvalues for the enabled edges are obtained from the Timing Memory, Thus,the Frame Processor formats wave shapes.

[1020] Mapping Methodology

[1021] The methodology is to map all the WaveformTable blocks on a perpin basis to LTSs in the tester. If tester hardware supports 4 LTSs, theuser can define a maximum of 4 WaveformTable blocks. Each WaveformTableblock can have a maximum of n waveform definitions for the testerdigital module.

[1022] The Timing-Map file provides a mapping of LogicalWaveformSelectors defined in the Timing-Map block to the WaveformTablefor the module in open architecture test system. In this case the testersupports up to 256 Logical WaveformSelectors. In open architecture testsystem system, the Logical WaveformSelectors map directly to the GTSs.The Pattern compiler depends on both the Timing-Map and the Timingblocks to be able to compile the pattern files. However if the waveformcharacters in the WaveformTables of the Timing block are unchanged orthe WaveformSelector mappings in the Timing-Map block are unchanged,there is no need to re-compile the pattern.

[1023] Example Using this Mapping Methodology

[1024] To illustrate the mapping into a tester Digital Module thefollowing assumptions are made: the Frame Processor is set to the FPmode; and CTV and MTV bits are set so total number of GTS bits is 6 andthe total number of Timing Bank Selector bits is 4.

[1025] Each WaveformTable defined in the Timing block is mapped to adistinct LTS within the Timing file. This is done on a per-pin basis.Thus WaveformTable seq1 is mapped to LTS1. In the case of the “SIG” pinall 8 possible waveform entries are used up. However the “CLK” pinrequires a single waveform entry and thus uses up a single row in theWaveform memory (WFT) and the Waveform Timing memory (WTM).

[1026] The mapping of the first 2 physical waveforms of the “SIG” pin isillustrated in FIG. 11. As this WaveformTable maps two waveformcharacters that need separate configurations of the edges, we end upallocating two entries in the Waveform memory (WFT) 1112 and theWaveform Timing memory (WTM) 1114. The shape of the waveform is storedin the WFM and the timing details are stored in the WTM. One embodimentof the module has a total of 6 timing edges T1, T2, T3, T4, T5 and T6.These map directly to the Events E1, E2, . . . defined in the waveformswithin a Edge Resource section of the Timing block. If more than 6events are defined in the Timing block and this is used with a the abovemodule, it will result in an error.

[1027] In the example of FIG. 11, the first waveform character “0” usesTiming Edge T1 to program the “Force Down” or “D” event, which occurs attime 10 ns into the cycle. Timing Edge T2 is also used to generate a“Force Down” or “D” event at time 30 ns. Finally Timing Edge T3 is usedto generate a “Force Off” or “Z” event at time 45 ns.

[1028] The second waveform character “1” uses Timing Edge T1 to programthe “Force Up” or “U” event, which occurs at time 10 ns into the cycle.Timing Edge T2 is also used to generate a “Force Down” or “D” event attime 30 ns. Finally Timing Edge T3 is used to generate a “Force Off” or“Z” event at time 45 ns.

[1029] In this fashion, the WFCs are mapped into the WFM memory and WTMmemory of the Frame Processor. The final setup of Waveform Memory WFM ofLTS1 for pin “SIG” is illustrated in Table 2 below. TABLE 2 Index (WFC)T1Set T1ReSet T2Set T2ReSet T2Drel T2Dret EXPH EXPHZ 0 0 1 1 1 1 1 1 2 d1 1 3 u 1 1 4 L 5 H 1 6 m 7 n 1 Index T3Set T3ReSet T3Drel T3Dret T4DrelT4Dret EXPL EXPHZ 0 1 1 1 2 1 3 1 4 1 5 6 1 7

[1030] The final setup of Waveform Timing Memory WTM of LTS1 for pin“SIG” is illustrated in Table 3 below. TABLE 3 Index (WFC) T1 T2 EXPH T3T4 EXPL 0 0 10ns 30ns 45ns 1 1 10ns 30ns 45ns 2 d 12ns 32ns 42ns 3 u12ns 32ns 42ns 4 L 17ns 5 H 17ns 6 m 15ns 7 n 15ns

[1031] The “CLK” pin uses up a single waveform and thus the WFM and WFTfor this pin are very simple. The final setup of Waveform Memory WFM ofLTS1 for the “CLK” pin is illustrated in Table 4 below. TABLE 4 Index(WFC) T1Set T1ReSet T2Set T2ReSet T2Drel T2Dret EXPH EXPHZ 0 1 1 1 1 2 34 5 6 7 Index T3Set T3ReSet T3Drel T3Dret T4Drel T4Dret EXPL EXPHZ 0 1 23 4 5 6 7

[1032] The final setup of Waveform Timing Memory WTM of LTS2 isillustrated in Table 5 below. TABLE 5 Index (WFC) T1 T2 EXPH T3 T4 EXPL0 1 20ns 40ns 1 2 3 4 5 6 7

[1033] The TimingMap block explicitly maps out the WaveformSelectors tothe Waveform tables of the Timing block. For a tester system this boilsdown to setting up the Timing Set Scrambler (TSS) memory. The TSSbasically contains a mapping from the GTS to the LTS that holds thesettings. The TSS setup for our example for pin SIG will look like Table6 below. TABLE 6 GTS LTS 0 (wfs1) 1 1 (wfs2) 1 2 (wfs3) 2 3 (wfs4) 1 4(wfs5) 3 5 (wfs6) 1 . . . N (wfs1) 1 . . . 255

[1034] Finally after the TSS and LTS setup mappings are resolved, thePattern Compiler can use this information to program the pattern withthe correct waveform table (LTS) and the correct waveform character touse. Thus our example pseudo-pattern considering only pin “SIG” isillustrated in FIG. 11. Note that this compilation has no dependency onthe Timing block and only depends on the Timing-Map block.

[1035] G. Tester Operation

[1036] This section describes the basic operation of the testeroperating system (TOS). The activities considered in this section are:

[1037] system initialization

[1038] Test Plan loading

[1039] Pattern loading

[1040] Running a Test Plan

[1041] Running an individual Test

[1042] System Initialization

[1043] In order to initialize the system in one embodiment, certainassumptions must be satisfied, and certain conditions must be met. Thefollowing sub-section lists these.

[1044] Preconditions

[1045] Copies of the relevant system software components have a centralstore, whose location is known to the System Controller. This may be onthe System Controller itself, or on another system with a networkmounted directory (or known to the SYSC via another mechanism)—whateverthe mechanism, before the system can function, all software must be madeavailable to the System Controller for use. This software includes:

[1046] vendor hardware control (i.e., module software) DLLs,

[1047] standard or user test class DLLs, and

[1048] user test plan DLLs.

[1049] The system module configuration file is available on the SystemController. Recall that this file allows the user to specify thephysical configuration of the tester, e.g., the physical location andtype of each module in the system chassis, as well as the names of themodule software DLLs.

[1050] The system configuration file is available on the SystemController. Recall that this file contains the list of Site Controllersin the system, as well as a map of

[1051] Site Controller hostnames to Switch Matrix input port addresses.Site controllers have a service called the Site Configuration Manager(SCM) running. This service is responsible for determining what hardwareis installed in each slot, by a process termed “hardware discovery”. Itis also responsible for participating in the system initializationprocess with the System Controller. Note that the Switch Matrixoperation protocol dictates, in one embodiment, that the SCM on a singleSite Controller, with Switch Matrix input port connection address 1,should always be used to configure the Switch Matrix connections to themodules. Recall that this “special” site is denoted as SITEC-1.

[1052] The System Controller is responsible for providing each SiteController's SCM with its Switch Matrix connection address.

[1053] Each Site controller's SCM is capable of starting a processcalled the Test Plan Server (TPS). The Test Plan Server on each SiteController is ultimately responsible for containing and executing theuser's test plan (or test plans, in the case where a single SiteController is running tests on multiple DUTs).

[1054] Initialization Phase I: System Validation

[1055] Once the above assumptions and preconditions have been satisfied,system initialization first proceeds with a system validation step asfollows:

[1056] 1. The System Controller reads the system and moduleconfiguration files to initialize the user-specified view of the system.

[1057] 2. Using the specified system configuration information, theSystem Controller verifies that the specified Site Controllers arealive, reachable, and ready (i.e., have SCMs running). Any error duringthis verification step will cause a system error to be raised, andinitialization to be aborted.

[1058] 3. The System Controller then instructs the SCM service atSITEC-1 to configure the switch matrix to have access to all hardwaremodules, and requests it to perform hardware discovery.

[1059] 4. The SCM service at SITEC-1 polls all available module slots(known hardware locations) for {vendor, hardware} tuples and generates amap of {vendor, hardware} tuples to slots. At conclusion, this poll hasthus identified the entire set of (vendor, hardware, slot) bindings thatexist in the complete system. The results of this poll are sent to theSystem Controller.

[1060] 5. The System Controller verifies that the results of the abovehardware discovery step match the user-specified configuration in themodule configuration file. Any error during this verification step willcause a system error to be raised, and initialization to be aborted.

[1061] 6. The System Controller then loads a default environment (suchas search paths for module DLLs, pattern lists, patterns, test planDLLs, test class DLLs, etc.) from the environment setup file(s) atwell-known location(s).

[1062] 7. The System Controller ensures that all identified modulesoftware DLLs exist. If one is not available on the System Controller,it is retrieved from the central store, if possible; otherwise, a systemerror is raised, and initialization is aborted.

[1063] Initialization Phase II: Site Configuration (Optional)

[1064] Site configuration, or site partitioning, involves thesoftware-level assignment of the available system hardware modules todifferent sites (i.e., to service multiple DUTs). Recall thatsite-partitioning information is provided in a socket file.

[1065] The tester system allows site (re-)partitioning to be performedboth as part of a test plan load (since each test plan is associatedwith a particular socket), and as an independent user-callable step. Inthe latter case, the user initiates the site partitioning by providing asocket file that is used solely to partition the system. This isespecially useful during system initialization in the case of multi-DUTtesting where each site tests a different DUT type. However, this stepis optional during the initialization stage, and the user can choose notto have it performed, opting instead to allow a test plan load topartition the system appropriately.

[1066] Whatever the means chosen to effect site partitioning (by anindependent call or implicitly through a test plan load), the mechanismis the same. This mechanism is described below.

[1067] 1. Given the socket, the System Controller first determineswhether the currently existing system partition is compatible with thesocket, or whether a re-partitioning is necessary. The default partitionduring initialization is one in which all available modules areconnected to SITEC-1. The remaining steps below are performed only ifre-partitioning is needed.

[1068] 2. The System Controller sends a configuration message to eachSite Controller SCM to re-configure itself with the number andidentities of DUT sites that are enabled for it under the new socket.Note that this is a general procedure, and handles the case where thenumber of DUT sites controlled by a Site Controller is one. The newsocket information is also conveyed to the SCMs.

[1069] 3. Each SCM stops the running TPS, if any, and starts a new one,initializing it with the new socket, and the number and identities ofDUT sites that are enabled for it under the new socket.

[1070] 4. The System Controller determines which sites need what subsetsof the required system modules. While doing this, it also prepareshardware slot information for the sites. The net result is, for eachsite, a list of slots versus module DLLs assigned to that site. Thissite-specific list will be denoted as the Site Module DLL Slot List(SITE-MDSL).

[1071] 5. The System Controller provides the appropriate SITE-MDSL, aswell as the necessary module DLLs, to each SCM. Each SCM in turn makesthis information available to the newly-started TPS.

[1072] 6. The System Controller then requests SITEC-1 to configure theSwitch Matrix for the proper site-to-slot connections, that is, forsite-partitioned operation.

[1073] 7. The TPSs on sites 1 through n load the DLLs specified in theirSITE-MDSL. Each of these DLLs has a function named initialize( ) whichtakes an array of slot numbers. The TPS calls initialize( ) with theappropriate slot lists for that module type. On any malfunctions at thispoint, a system error is raised, and initialization is aborted. Theinitialize( ) method does the following:

[1074] a. Creates concrete classes based on a standard interfaceIXxXModule. For example, a DLL associated with a digital module willcreate a single IPinModule-based object to service each slot it isassociated with.

[1075] b. Creates concrete classes based on interface IResource, one foreach “resource unit” in the module. Again, for a digital module, eachIPinModule-based object will create ITesterPin-based objects for allpins in the collection of slots occupied by digital modules.

[1076] 8. The TPSs on sites 1 through n then call getXXXModule( ) oneach loaded module DLL to retrieve module contents information.

[1077] 9. Each call to getXXXModule( ) returns a <VendorHWType>Moduleclass object as an IModule pointer (e.g., AdvantestPinModule). Each suchIModule pointer is cached by the TPS, which makes these available toframework/user code. Note that the collection of IModules, IResources,etc. are persistent (at least for the lifetime of the TPS).

[1078] 10. Once the above steps are complete, the TPS starts to listen() on its assigned (well-known) port. This signals to the SystemController that the TPS is “ready” to begin normal (i.e.,site-partitioned) operation.

[1079] Test Plan Load

[1080] This section describes the steps by which a user Test Plan DLL isloaded on a Site Controller (for single or multiple DUT testing).

[1081] Once system initialization (and optionally, initial sitepartitioning) has been completed, user test plans can be loaded. Theloading of a user test plan on a Site Controller proceeds as follows:

[1082] 1. The System Controller first loads the test plan DLL into itsown process space, querying it for its associated socket file and itsDUT type identifier. This information is used to identify the site(s)running this test plan, and hence, the Site Controller(s) that this testplan would be loaded on.

[1083] 2. The System Controller then uses the socket informationassociated with the test plan to initiate the re-partitioning process asoutlined above.

[1084] 3. The System Controller extracts the list of test class DLLsused by the test plan from the test plan DLL, and once the SystemController has verified that the TPS is ready to begin normal (i.e.,site-partitioned) operation, sends the test class DLLs, and, finally,the test Plan DLL itself, to the appropriate TPS.

[1085] 4. The TPS calls LoadLibrary( ) to load it into its processspace. It calls a well-known function on the DLL to create as manyTestPlan objects as the number of sites (i.e., DUTs) it is servicing.

[1086] 5. The TPS initializes the TestPlan object(s) with the necessarytester framework objects. During initialization, the TPS loads theappropriate DLLs for the test classes used by the TestPlan object(s)into the process space, and creates the test class instances.

[1087] 6. The TPS sets up the communications channel to/from the SystemController to the TestPlan object(s).

[1088] 7. The System Controller communicates with the TPS, and buildsits proxies for the TestPlan object(s).

[1089] The concludes the successful load of the user's Test Plan on aSite Controller.

[1090] Running a Test Plan

[1091] The method to execute all tests in a test plan according to thepre-defined flow logic is as follows:

[1092] 1. The user's application transmits a RunTestPlan message to theTPS. The TPS sends an ExecutingTestPlan message to all connectedapplications. The TPS then calls execute( ) on the Test Plan.

[1093] 2. Testing multiple DUTs with a single Site Controller isperformed using multiple threads on that Site Controller, one per DUT.Each thread runs a different, independent instance of the same TestPlanobject. Since, in this case, module control software DLLs might beshared across DUTs, the module commands for hardware communication arerequired to take a DUT identifier parameter.

[1094] 3. The TestPlan object iterates over each test in its collection(alternatively, tells its Flow object to process each test according tothe flow logic), calling preExec( ), execute( ), and postExec( ).

[1095] 4. As each test executes, status messages are sent back to allconnected applications.

[1096] Executing a Single Test

[1097] A user may wish to execute a single test in a test plan insteadof all tests. For single test execution, the method is as follows.

[1098] 1. User application transmits a RunTest message to the TPS; theTPS sends an ExecutingTest message to all connected applications. TheTPS then calls executeTest( ) on the Test Plan, specifying the test torun.

[1099] 2. The Test Plan object executes the specified test by callingpreExec( ), execute( ), and postExec( ) on that test object.

[1100] 3. When the test executes, it sends status messages back to allconnected applications.

[1101] Although the invention has been described in conjunction withparticular embodiments, it will be appreciated that variousmodifications and alterations may be made by those skilled in the artwithout departing from the spirit and scope of the invention. Theinvention is not to be limited by the foregoing illustrative details,but rather interpreted according to the scope of the claims.

What is claimed is:
 1. A method for developing a test program in generalpurpose C/C++ constructs, the test program for testing a semiconductorintegrated circuit (IC) in a semiconductor test system, the methodcomprising: describing test system resources, test system configuration,and module configuration in general-purpose C/C++ constructs for thedevelopment of a test program to test the IC on the semiconductor testsystem; describing a test sequence in general-purpose C/C++ constructsfor the development of the test program to test the IC on thesemiconductor test system; describing a test plan in general-purposeC/C++ constructs for the development of the test program to test the ICon the semiconductor test system; describing test conditions ingeneral-purpose C/C++ constructs for the development of the test programto test the IC on the semiconductor test system; describing testpatterns in general-purpose C/C++ constructs for the development of thetest program to test the IC on the semiconductor test system; anddescribing timing of the test patterns in general-purpose C/C++constructs for the development of the test program to test the IC on thesemiconductor test system.
 2. The method of claim 1, wherein describingtest system resources comprises: specifying a resource type, wherein theresource type is associated with at least one test module for applying atest to the IC; specifying a parameter type associated with the resourcetype, and specifying a parameter of the parameter type.
 3. The method ofclaim 1, wherein describing test system configuration comprises:specifying a site controller for controlling at least one test module,each test module for applying a test to the IC; and specifying an inputport of a module connection enabler, wherein the test system couples thesite controller to the module connection enabler at the input port, andthe module connection enabler couples the site controller to the atleast one test module.
 4. The method of claim 3, wherein the moduleconnection enabler is a switch matrix.
 5. The method of claim 1, whereindescribing module configuration comprises: specifying a moduleidentifier for specifying a module type; specifying executable code forcontrolling a test module of the module type specified by the moduleidentifer, the test module for applying a test to the IC; and specifyinga resource type associated with the test module.
 6. The method of claim5, the method further comprising specifying a slot identifier forspecifying an output port of a module connection enabler, wherein thetest system couples the test module to the module connection enabler atthe output port, and the module connection enabler couples the testmodule to a corresponding site controller.
 7. The method of claim 6,wherein the module connection enabler is a switch matrix.
 8. The methodof claim 5, wherein the executable code is a dynamic link library. 9.The method of claim 5, further comprising specifying a vendor identifierfor identifying the provider of the test module.
 10. The method of claim5, further comprising specifying an identifier of the maximum number ofresource units available in connection with the resource type.
 11. Themethod of claim 5, wherein the resource type is digital tester pins andthe resource units are tester channels.
 12. The method of claim 5,wherein the resource type is analog tester pins and the resource unitsare tester channels.
 13. The method of claim 5, wherein the resourcetype is RF tester pins and the resource units are tester channels. 14.The method of claim 5, wherein the resource type is power supply pinsand the resource units are tester channels.
 15. The method of claim 5,wherein the resource type is digitizer pins and the resource units aretester channels.
 16. The method of claim 5, wherein the resource type isarbitrary waveform generation pins and the resource units are testerchannels.
 17. The method of claim 5, wherein the resource type isassociated with resource units, the method further comprising specifyingan indicator relating to which resource units are disabled.
 18. Themethod of claim 18, wherein resource units indicated as disabledrepresent defective resource units of the test module.
 19. The method ofclaim 1, wherein describing test conditions comprises: specifying atleast one test condition group.
 20. The method of claim 19, whereindescribing test conditions further comprises: specifying at least onespecification set including at least one variable; and specifying aselector for selecting an expression to be bound to a variable.
 21. Themethod of claim 20, wherein association of the test condition group witha selector for the at least one specification set defines a testcondition.
 22. The method of claim 21, wherein the test condition is anobject.
 23. The method of claim 1, wherein describing a test sequencecomprises specifying: a result of executing a flow or test; an actionbased upon the result; and a transition to another flow or test basedupon the result.